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

> -----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
methodology
> 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
previously
> 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
patch
> that has already been committed [2]. This general approach worked really
> well on my laptop, which has a slowish fsync of about 8 milliseconds
(8,000
> microseconds), for which a commit_delay setting of 4,000 (microseconds)
> seemed to clearly work best, on both insert and tpc-b benchmarks [3].

<snip>

>
> 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
cases,

Should probably read

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

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

Regards

David Rowley