Greg Smith <greg@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
