On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Smith <g...@2ndquadrant.com> writes: >> And the expensive part of the overhead beyond the delay itself is >> CountActiveBackends(), which iterates over the entire procArray >> structure. > > I could have sworn we'd refactored that to something like > bool ThereAreAtLeastNActiveBackends(int n) > which could drop out of the loop as soon as it'd established what we > really need to know. In general it's unclear that this'd really save > much, since in a large fraction of executions the answer would be > "no", and then you can't drop out of the loop early, or at least not > very early. But it clearly wins when n == 0 since then you can just > return true on sight. > >> As for why this somewhat weird feature hasn't been removed yet, it's >> mainly because we have some benchmarks from Jignesh proving its value in >> the hands of an expert. > > Removal has been proposed several times, but as long as it's off by > default, it's fairly harmless to leave it there. I rather expect > it'll stay as it is until someone proposes something that actually works > better. In particular I see no advantage in simply deleting some of the > parameters to the existing code. I'd suggest that we just improve the > coding so that we don't scan ProcArray at all when commit_siblings is 0. > > (I do agree with improving the docs to warn people away from assuming > this is a knob to frob mindlessly.) > > regards, tom lane >
In that case I propose that we support commit_siblings=0 which is not currently supported. Minimal value for commit_siblings is currently 1. If we support commit_siblings=0 then it should short-circuit that function call which is often what I do in my tests with commit_delay. Thanks. Regards, Jignesh -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
