Re: Postgres 8.3 archive_command - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Postgres 8.3 archive_command
Date
Msg-id Pine.GSO.4.64.0711211750540.21556@westnet.com
Whole thread Raw
In response to Re: Postgres 8.3 archive_command  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: "Gregory Williamson"
Date:
Subject: Re: 8.3devel slower than 8.2 under read-only load
Next
From: "Guillaume Smet"
Date:
Subject: Re: 8.3devel slower than 8.2 under read-only load