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

On Thu, Nov 15, 2012 at 9:56 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> On 11/15/12 12:19 AM, Albe Laurenz wrote:
>>
>> If there is an agreement that half the sync time as reported by
>> pg_test_fsync is a good value, would it make sense to have initdb test
>> sync time and preset commit_delay?
>
>
> Peter has validated this against a good range of systems, but it would be
> optimistic to say it's a universal idea.
>
> My main concern with this would be the relatively common practice of moving
> the pg_xlog directory after initdb time.  Sometimes people don't know about
> the option to have initdb move it.  Sometimes the drive to hold pg_xlog
> isn't available when the database is originally created yet.  And the camp I
> fall into (which admittedly is the group who can take care of this on their
> own) will move pg_xlog manually and symlink it on their own, because that's
> what we're used to.

An even more common usecase for this, I think, is "I installed from a
package that ran initdb for me".. I still think manual moving of
pg_xlog is a lot more common than using the initdb option in general.


> 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.


--Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/