On Mon, Jan 28, 2013 at 04:29:12AM +0000, Peter Geoghegan wrote:
> On 28 January 2013 03:34, Noah Misch <noah@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.