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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com