Re: Very slow planning performance on partition table

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Very slow planning performance on partition table
Дата
Msg-id CAMkU=1ydmpt9XRMxt0sPNnQsXEoF_c7bgp2kHxtDbPNGg5Vj5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Very slow planning performance on partition table  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Very slow planning performance on partition table  (Rural Hunter <ruralhunter@gmail.com>)
Re: Very slow planning performance on partition table  (Rural Hunter <ruralhunter@gmail.com>)
Список pgsql-performance

On Sun, Jul 27, 2014 at 9:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rural Hunter <ruralhunter@gmail.com> writes:
>> Does that indicate something? seems it's waiting for some lock.

Yeah, that's what the stack trace suggests.  Have you looked into pg_locks
and pg_stat_activity to see which lock it wants and what's holding said
lock?

If it were waiting on a pg_locks lock, the semop should be coming from ProcSleep, not from LWLockAcquire, shouldn't it?

I'm guessing he has a lot of connections, and each connection is locking each partition in shared mode in rapid fire, generating spin-lock or cache-line contention.

Cheers,

Jeff

В списке pgsql-performance по дате отправления:

Предыдущее
От: Rural Hunter
Дата:
Сообщение: Re: Very slow planning performance on partition table
Следующее
От: worthy7
Дата:
Сообщение: Re: Full text search with ORDER BY performance issue