Thread: pg_test_fsync output and commit_delay

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

> The attached simple patch alters the output produced by pg_test_fsync,
> so that we also see the average sync time per op. 

Good idea.  A median would be even better, but harder to calculate, I
imagine.  You might consider providing a maximum, too.

> 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.

I'll see what I can do.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com