I propose that we try and develop better commit_delay advice, to make it easier to set the parameter in a way that actually helps performance. I have been researching a way to make commit_delay adaptive, though have yet to develop any further insight that is worth sharing. This may change.
The attached simple patch alters the output produced by pg_test_fsync, so that we also see the average sync time per op. The pg_test_fsync docs have had minor alterations too. Hopefully, another doc patch will follow that builds upon this, and actually firmly recommends taking a particular course of action when setting commit_delay - my previous observations about what helped throughput, though supported by Greg Smith, have not been scrutinised enough just yet, I feel. For now, the equivocated wording of my doc alterations (that raw wal_sync_method file sync time might *somehow* be useful here) seems appropriate. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
pg_test_fsync.v1.2012_09_08.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
