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
move_delay_2012_05_29.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
