Message-ID: <4D2610F3.8070407@agliodbs.com>
Date: Thu, 06 Jan 2011 10:58:59 -0800
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: Jeff Janes <jeff.janes@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Wrong docs on wal_buffers?
References: <4D24D7DE.6020507@agliodbs.com>
	<AANLkTi=YLCEGcwa-9hFYykRgTfUVDhZrwNGo7qaJZnRC@mail.gmail.com>
In-Reply-To: <AANLkTi=YLCEGcwa-9hFYykRgTfUVDhZrwNGo7qaJZnRC@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> And the risks are rather asymmetric.  I don't know of any problem from
> too large a buffer until it starts crowding out shared_buffers, while
> under-sizing leads to the rather drastic performance consequences of
> AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding
> the WALInsertLock,

Yes, performance testing has bourne that out.  Increasing wal_buffers to
between 1MB and 16MB has benfitted most test cases (DBT2, pgBench, user
databases) substantially, while an increase has never been shown to be a
penalty.  Increases above 16MB didn't seem to help, which is
unsurprising given the size of a WAL segment.

> But I wonder if initdb.c, when selecting the default shared_buffers,
> shouldn't test with wal_buffers = shared_buffers/64 or
> shared_buffers/128, with a lower limit of 8 blocks, and set that as
> the default.

We talked about bumping it to 512kB or 1MB for 9.1.  Did that get in?
Do I need to write that patch?

It would be nice to have it default to 16MB out of the gate, but there
we're up against the Linux/FreeBSD SysV memory limits again.  When are
those OSes going to modernize?

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com