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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
