Re: auto-sizing wal_buffers - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: auto-sizing wal_buffers
Date
Msg-id AANLkTimZVFNcCuQ+iDCs2aCQ0HXyf3WiAkYmUR6S9Vsc@mail.gmail.com
Whole thread Raw
In response to Re: auto-sizing wal_buffers  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 1/14/11 10:51 PM, Greg Smith wrote:
>>
>> !         Since the data is written out to disk at every transaction
>> commit,
>> !         the setting many only need to be be large enough to hold the
>> amount
>> !         of WAL data generated by one typical transaction.  Larger values,
>> !         typically at least a few megabytes, can improve write performance
>> !         on a busy server where many clients are committing at once.
>> !         Extremely large settings are unlikely to provide additional
>> benefit.
>
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?

I would turn it around and ask if there is any theoretical reason it
would not benefit?
(And if so, can they be cured soon?)


>  Certainly there have been no test results to show any.

Did the tests show steady improvement up to 16MB and then suddenly
hit a wall?  (And in which case, were they recompiled at a larger segment
size and repeated?)  Or did improvement just peter out because 16MB is really
quite a bit and there was just no need for it to be larger independent
of segment size?

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: Re: psql: Add \dL to show languages
Next
From: Andy Colson
Date:
Subject: Re: plperlu problem with utf8 [REVIEW]