Re: Very slow planning performance on partition table

Поиск
Список
Период
Сортировка
От Rural Hunter
Тема Re: Very slow planning performance on partition table
Дата
Msg-id 53D6E67B.1040003@gmail.com
обсуждение исходный текст
Ответ на Re: Very slow planning performance on partition table  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
<div class="moz-cite-prefix">在 2014/7/29 1:29, Jeff Janes 写道:<br /></div><blockquote
cite="mid:CAMkU=1ydmpt9XRMxt0sPNnQsXEoF_c7bgp2kHxtDbPNGg5Vj5w@mail.gmail.com"type="cite"><div dir="ltr"><div
class="gmail_extra"><br/><div class="gmail_quote"><div>If it were waiting on a pg_locks lock, the semop should be
comingfrom ProcSleep, not from <span
style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">LWLockAcquire,shouldn't it?</span></div><div><span
style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br/></span></div><div><font color="#000000"
face="arial,sans-serif">I'm guessing he has a lot of connections, and each connection is locking each partition in
sharedmode in rapid fire, generating spin-lock or cache-line contention.</font></div><div><font color="#000000"
face="arial,sans-serif"><br /></font></div><div>Cheers,</div><div><br
/></div><div>Jeff</div></div></div></div></blockquote>Yes. I have a lot of connections and they maybe coming together
anddoing the same update statement without partition key on the partition table.<br /> 

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

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