From: Josh Berkus <josh@agliodbs.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: auto-sizing wal_buffers
Date: Sat, 15 Jan 2011 14:34:11 -0800
Message-ID: <4D3220E3.20804@agliodbs.com> (raw)
In-Reply-To: <4D314406.3000703@2ndquadrant.com>
References: <AANLkTik3mZ3sTfbHQW-1B44NRMkUzRsMnPb8g-HtttVv@mail.gmail.com>
<AANLkTimQ3+osgAEH4meS97FmLN-4evSTS2W6fctov=jY@mail.gmail.com>
<AANLkTinhU9EEPGM29S+KH=qK4t-mLhBBNAaLCGQSx-4y@mail.gmail.com>
<20767.1294964709@sss.pgh.pa.us>
<4D314406.3000703@2ndquadrant.com>
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?
Certainly there have been no test results to show any.
If we don't know, keep it vague, but otherwise I suggest:
"Settings larger than the size of a single WAL segment (16MB by default)
are unlikely to produce any benefit."
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: josh@agliodbs.com, greg@2ndquadrant.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, magnus@hagander.net
Subject: Re: auto-sizing wal_buffers
In-Reply-To: <4D3220E3.20804@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox