Uh, I change my mind about commit_delay + commit_siblings (sort of)

The attached very simple patch moves the commit_delay +
commit_siblings sleep into XLogFlush, where the leader alone sleeps.
This appears to be a much more effective site for a delay.

Benchmark results, with and without a delay of 3000ms (commit_siblings
is 0 in both cases) are available from:

http://leadercommitdelay.staticloud.com

The only way this differed from my usual setup for these benchmarks
was that, as it happened, shared_buffers was set to 256MB, which would
of course have affected wal_buffers actual value, which was 8MB.

I surmise that the reason this works so well is that it increases the
rate of batching at lower client counts, without needlessly delaying
each and every follower beyond when their transaction is likely to
have committed. A more detailed analysis will have to wait for
tomorrow.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services