| От | Sören Meyer-Eppler |
|---|---|
| Тема | Re: PostgreSQL 9.0.4 blocking in lseek? |
| Дата | |
| Msg-id | 4EAEAC21.5080209@google.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL 9.0.4 blocking in lseek? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: PostgreSQL 9.0.4 blocking in lseek?
|
| Список | pgsql-performance |
> embedded in often-executed plpgsql functions, for instance. Can you
> identify which table the lseeks are issued against?
I wouldn't know how? I'm just using htop and "s" on the postgres process
to find these...
> (Now, having said that, I don't see how that type of theory explains no
> CPU load.
My bad sorry. I was relaying information from the guy administering the
server. It turns out that "no CPU load" really meant: only one of the
cores is being utilized. On a 16 core machine that looks like "no load"
but of course for the individual query still means 100%.
> But you're really going to need to provide more info before
> anyone can explain it, and finding out what the lseeks are on would be
> one good step.)
I have attached two of the offending execution plans. Anything obviously
wrong with them?
thank you for looking into it!
Sören
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера