On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Smith <greg@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