Re: Postgres 8.3 archive_command

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgres 8.3 archive_command
Date: 2007-11-21 23:22:06
Message-ID: Pine.GSO.4.64.0711211750540.21556@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 21 Nov 2007, Tom Lane wrote:

> Whether 16MB is still a reasonable default segment size is worth
> questioning, though I don't think that increasing it is an open-and-shut
> proposition.

I don't think it's a reasonable change to make right now. I think 16MB is
already too big for some people, reasonable for most, and only too small
for a tiny portion of users that have fairly powerful systems.
Incorporating what you said, there are two downsides to a bigger segment
that immediately come to mind:

-More garbage in unfilled segments means higher archiving overhead in some
configurations. There are already people annoyed enough about this
problem to be coding around it (I'm thinking of Kevin Grittner's
pg_clearxlogtail).

-The way new WAL segments get created can block clients while they wait
for that write. As the segments gets larger this problem becomes worse,
and there are many situations where reducing worse-case latency is far
more important than throughput.

There's already been talk of improving the latter by having a background
process create the segments, but that doesn't make the problem go away
altogether; it just makes it less likely to happen. I'd at least like to
see that change and an official log tail cleaning mechanism both available
before considering a change to the default WAL size.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Smet 2007-11-21 23:30:47 Re: 8.3devel slower than 8.2 under read-only load
Previous Message Gregory Williamson 2007-11-21 23:07:24 Re: 8.3devel slower than 8.2 under read-only load