Re: Group commit and commit delay/siblings

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