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.
For finding cost delayed statements that are causing trouble because
they are holding locks, the only place I've thought of that runs
infrequently and is poking at the right data is the deadlock detector.
Turning that into a more general mechanism for finding priority
inversion issues is an interesting idea. It's a bit down the road from
what I'm staring at now though.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
