Re: Why do we still have commit_delay and commit_siblings?

On 14 May 2012 00:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, May 13, 2012 at 7:17 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>> Have I missed something? Why do we keep around this foot-gun that now
>> appears to me to be at best useless and at worst harmful? I can see
>> why the temptation to keep this setting around used to exist, since it
>> probably wasn't too hard to get good numbers from extremely synthetic
>> pgbench runs, but I cannot see why the new adaptive implementation
>> wouldn't entirely shadow the old one even in that situation.
>
> It seems that, with the new code, when there are a lot of people
> trying to commit very frequently, they tend to divide themselves into
> two gangs: everybody in one gang commits, then everyone in the other
> gang commits, then everyone in the first gang commits again, and so
> on.  Assuming that the transactions themselves require negligible
> processing time, this provides 50% of the theoretically optimum
> throughput.

Keeping a parameter without any clue as to whether it has benefit is
just wasting people's time.

We don't ADD parameters based on supposition, why should we avoid
removing parameters that have no measured benefit?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services