From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(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-29 03:48:37 |
Message-ID: | 20130129034837.GB24443@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 28, 2013 at 04:29:12AM +0000, Peter Geoghegan wrote:
> 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?
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-29 04:08:33 | Re: enhanced error fields |
Previous Message | Robert Haas | 2013-01-29 03:36:38 | Re: Hm, table constraints aren't so unique as all that |