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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books