Re: Group commit and commit delay/siblings

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