Horton
Menu

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

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Greg Smith <greg@2ndquadrant.com>, Albe Laurenz <laurenz.albe@wien.gv.at>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-11-15T10:44:20Z
Lists: pgsql-hackers 
On 15 November 2012 10:04, Magnus Hagander <magnus@hagander.net> wrote:
>> I would rather see this just turn into one of the things a more general
>> tuning tool knew how to do, executing against a fully setup system. Having a
>> useful implementation of commit_delay and useful docs on it seems like
>> enough of a jump forward for one release.  Moving fully into auto-tuning
>> before getting more field feedback on how that works out is pretty
>> aggressive.
>
> +1.

I am inclined to agree. I did attempt to use the instrumentation
macros to have commit_delay set adaptively at runtime, which would
have at least addressed this concern, but that just didn't work as
well as this.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add microsecs/op display to pg_test_fsync utility