Re: Redesigning checkpoint_segments

On 6/7/13 2:43 PM, Robert Haas wrote:
>> name.  What I would like to see is a single number here in memory units that
>> replaces both checkpoint_segments and wal_keep_segments.
>
> This isn't really making sense to me.  I don't think we should assume
> that someone who wants to keep WAL around for replication also wants
> to wait longer between checkpoints.  Those are two quite different
> things.

It's been years since I saw anyone actually using checkpoint_segments as 
that sort of limit.  I see a lot of sites pushing the segments limit up 
and then using checkpoint_timeout carefully.  It's pretty natural to say 
"I don't want to go more than X minutes between checkpoints".  The case 
for wanting to say "I don't want to go more than X MB between 
checkpoints" instead, motivated by not wanting too much activity to 
queue between them, I'm just not seeing demand for that now.

The main reason I do see people paying attention to checkpoint_segments 
still is to try and put a useful bound on WAL disk space usage.  That's 
the use case I think overlaps with wal_keep_segments such that you might 
replace both of them.  I think we really only need one control that 
limits how much WAL space is expected inside of pg_xlog, and it should 
be easy and obvious how to set it.

The more I look at this checkpoint_segments patch, the more I wonder why 
it's worth even bothering with anything but a disk space control here. 
checkpoint_segments is turning into an internal implementation detail 
most sites I see wouldn't miss at all.  Rather than put work into 
autotuning it, I'd be happy to eliminate checkpoint_segments altogther, 
in favor of a WAL disk space limit.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com