Re: Re: Doc patch making firm recommendation for setting the value of commit_delay - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Re: Doc patch making firm recommendation for setting the value of commit_delay
Date
Msg-id CAEYLb_W9Tq-22UhrmzTiiOTHbYS84u=1zKB-hnN70-69Eo=0xA@mail.gmail.com
Whole thread Raw
In response to Re: Re: Doc patch making firm recommendation for setting the value of commit_delay  (Noah Misch <noah@leadboat.com>)
Responses Re: Re: Doc patch making firm recommendation for setting the value of commit_delay
List pgsql-hackers
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? 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.

-- 
Regards,
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: allowing privileges on untrusted languages
Next
From: Tatsuo Ishii
Date:
Subject: Re: review: pgbench - aggregation of info written into log