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
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 |