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: http://www.postgresql.org/mailpref/pgsql-hackers
