On Thu, May 23, 2013 at 8:46 PM, Greg Smith <g...@2ndquadrant.com> wrote:
> On 5/23/13 7:34 PM, Claudio Freire wrote:
>> Why not make the delay conditional on the amount of concurrency, kinda
>> like the commit_delay? Although in this case, it should only count
>> unwaiting connections.
> The test run by commit_delay is way too heavy to run after every block is
> processed.  That code is only hit when there's a commit, which already
> assumes a lot of overhead is going on--the disk flush to WAL--so burning
> some processing/lock acquisition time isn't a big deal.  The spot where
> statement delay is going is so performance sensitive that everything it
> touches needs to be local to the backend.

Besides of the obvious option of making a lighter check (doesn't have
to be 100% precise), wouldn't this check be done when it would
otherwise sleep? Is it so heavy still in that context?

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to