Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Ok, I've collected more data. Looks like the case I was examining was
> idiosyncratic; most of these lock pile-ups involve 400 or more locks
> waiting held by around 20 different backends. Given this, taking 3
> seconds to sort that all out doesn't seem that unreasonable.
> Presumably there's a poll cycle of some sort for waiting statements?
No ... but if the lock requests were mutually exclusive, I could believe
it taking 3 seconds for all of the waiting backends to get their turn
with the lock, do whatever they were gonna do, commit, and release the
lock to the next guy.
> Anyway, the obvious answer is for the user to fix their application.
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Pavel Stehule||Date: 2010-11-18 06:14:24|
|Subject: Re: Query Performance SQL Server vs. Postgresql|
|Previous:||From: Greg Smith||Date: 2010-11-17 23:43:32|
|Subject: Re: How to achieve sustained disk performance of 1.25 GB
write for 5 mins|