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

Re: Doc patch making firm recommendation for setting the value of commit_delay

From: "David Rowley" <dgrowleyml(at)gmail(dot)com>
To: "'Peter Geoghegan'" <peter(at)2ndquadrant(dot)com>,"'PG Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doc patch making firm recommendation for setting the value of commit_delay
Date: 2012-11-15 02:24:03
Message-ID: 00ab01cdc2d8$4c904460$e5b0cd20$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Peter Geoghegan
> Sent: 15 November 2012 09:44
> To: PG Hackers
> Subject: [HACKERS] Doc patch making firm recommendation for setting the
> value of commit_delay
> Some of you will be aware that I've tried to formulate a good general
> recommendation for setting the value of commit_delay, in light of the
> improvements made in 9.3. I previously asked for help finding a
> for optimising commit_delay [1]. The documentation related to
> commit_delay still says that we don't know what might work well, though I
> don't think that's true any more.
> I found the time to do some benchmarks of my own - Greg Smith made
> available a server that he frequently uses for benchmarks. It was
> my observation that "half of raw single-page sync time as reported by
> pg_test_fsync for you wal_sync_method" worked best for commit_delay. I
> went so far as to modify pg_test_fsync to output average time per op in
> microseconds for each operation with commit_delay in mind, which is a
> that has already been committed [2]. This general approach worked really
> well on my laptop, which has a slowish fsync of about 8 milliseconds
> microseconds), for which a commit_delay setting of 4,000 (microseconds)
> seemed to clearly work best, on both insert and tpc-b benchmarks [3].

> Thoughts?

I think for sure, since the GUC maintained its original name, that the docs
need to be updated to let people know the background behaviour has changed
and may now be far more useful.
I've read through the patch. Only thing I see out of place is a small typo:

!    values of <varname>commit_siblings</varname> should be used is such

Should probably read

!    values of <varname>commit_siblings</varname> should be used *in* such

Thanks for doing all the benchmarks too. Good to see such a range of
different hardware tested.


David Rowley

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2012-11-15 02:28:19
Subject: Materialized views WIP patch
Previous:From: Robert HaasDate: 2012-11-15 02:22:41
Subject: Re: Enabling Checksums

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