On Thu, Nov 15, 2012 at 9:56 AM, Greg Smith <g...@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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
