From: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Doc patch making firm recommendation for setting the value of commit_delay |
Date: | 2013-01-28 04:29:12 |
Message-ID: | CAEYLb_W9Tq-22UhrmzTiiOTHbYS84u=1zKB-hnN70-69Eo=0xA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 January 2013 03:34, Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2013-01-28 04:47:58 | Re: review: pgbench - aggregation of info written into log |
Previous Message | Craig Ringer | 2013-01-28 04:15:37 | Re: allowing privileges on untrusted languages |