Re: [COMMITTERS] pgsql: Optimize commit_siblings in two ways to improve group commit.

Tom Lane wrote:
> I'm not entirely convinced that zero commit_siblings is a better
> default than small positive values, but it's certainly plausible.
>

Not being allowed to set it to zero was certainly a limitation worth
abolishing though; that has been the case before now, for those who
didn't see the thread on the performance list. I think that on the sort
of high throughput system likely to benefit from this behavior, whether
commit_siblings is zero or five doesn't matter very much--those people
should cross the siblings threshold very quickly regardless. The main
arguments in favor of making the default lower aren't as exciting now
that it jumps out of the loop early once finding the requisite number.

I like keeping the default at 5 though. It keeps the person who
experiments with increasing commit_delay from suffering when there are
in reality not a lot of active connections. There are essentially two
foot-guns you have to aim before you run into the worst case here, which
is making every single commit wait for the delay when there's really
only one active process committing.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books