On Mon, Jan 28, 2013 at 04:29:12AM +0000, Peter Geoghegan wrote: > On 28 January 2013 03:34, Noah Misch <n...@leadboat.com> wrote: > > On the EBS configuration with volatile fsync timings, the variability didn't > > go away with 15s runs. On systems with stable fsync times, 15s was no > > better > > than 2s. Absent some particular reason to believe 5s is better than 2s, I > > would leave it alone. > > I'm not recommending doing so because I thought you'd be likely to get > better numbers on EBS; obviously the variability you saw there likely > had a lot to do with the fact that the underlying physical machines > have multiple tenants. It has just been my observation that more > consistent figures can be obtained (on my laptop) by using a > pg_test_fsync --secs-per-test of about 5. That being the case, why > take the chance with 2 seconds?
I can't get too excited about it either way. > It isn't as if people run > pg_test_fsync everyday, or that they cannot set --secs-per-test to > whatever they like themselves. On the other hand, the cost of setting > it too low could be quite high now, because the absolute values (and > not just how different wal_sync_methods compare) is now important. True. You'd actually want to run the tool with a short interval to select a wal_sync_method, then test the chosen method for a longer period to get an accurate reading for commit_delay. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
