Re: how to investigate GIN fast updates and cleanup cycles?
От | Tom Lane |
---|---|
Тема | Re: how to investigate GIN fast updates and cleanup cycles? |
Дата | |
Msg-id | 25835.1440783160@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: how to investigate GIN fast updates and cleanup cycles? (Steve Kehlet <steve.kehlet@gmail.com>) |
Ответы |
Re: how to investigate GIN fast updates and cleanup cycles?
|
Список | pgsql-general |
Steve Kehlet <steve.kehlet@gmail.com> writes: > On Fri, Aug 28, 2015 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hm ... have you tried checking pg_locks to see if they're blocked on >> something identifiable? > Yes, I should have mentioned that, I have a cronjob going every minute > dumping out [blocked/blocking queries]( > https://gist.github.com/skehlet/fbf5f52e18149e14e520) and nothing has shown > up related to these queries (there were some other normal unrelated > results, so I believe the job+query itself are working). BTW, I think your query is probably missing some cases: ( blockingl.transactionid=blockedl.transactionid OR (blockingl.relation=blockedl.relation AND blockingl.locktype=blockedl.locktype) ) This supposes that locks of different strengths don't block each other, which is certainly wrong. I think you could probably just drop the check on locktype. You might want to tighten the WHERE to "WHERE blockingl.granted AND NOT blockedl.granted", as well. regards, tom lane
В списке pgsql-general по дате отправления: