Skip site navigation (1) Skip section navigation (2)

Re: Re: Doc patch making firm recommendation for settingthe value of commit_delay

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 settingthe value of commit_delay
Date: 2013-01-29 03:48:37
Message-ID: (view raw, whole thread or download thread mbox)
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.

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-29 04:08:33
Subject: Re: enhanced error fields
Previous:From: Robert HaasDate: 2013-01-29 03:36:38
Subject: Re: Hm, table constraints aren't so unique as all that

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group