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
Re: Very slow planning performance on partition table |
| Список | 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:Yeah, that's what the stack trace suggests. Have you looked into pg_locks
>> Does that indicate something? seems it's waiting for some lock.
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 по дате отправления: