Re: A few new options for CHECKPOINT - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: A few new options for CHECKPOINT
Date
Msg-id 3785B778-9FED-43DF-B543-64FC88A35823@amazon.com
Whole thread Raw
In response to Re: A few new options for CHECKPOINT  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 11/29/20, 7:21 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
> Checkpoints are always happening though, that's kind of my point..?
> Sure, you get lucky sometimes that the time you snapshot might have less
> outstanding WAL than at some other time, but I'm not convinced that this
> patch is really going to give a given user that much reduced amount of
> WAL that has to be replayed more than just randomly timing the
> snapshot, and if it's not clearly better, always, then I don't think we
> can reasonably document it as such or imply that this is how folks
> should implement snapshot-based backups.

I see your point.  Using a non-immediate checkpoint might help you
keep your recovery time slightly more consistent, but you're right
that it's likely not going to be a dramatic improvement.  Your
recovery time will be 1 minute versus 1-2 minutes or 2 minutes versus
2-4 minutes, not 3 seconds versus 5 minutes.

> Did you have other concrete examples that we could reference as to when
> it would be useful to use these options?

I don't have any at the moment.  I figured that if we're going to
allow users to manually trigger checkpoints, we might as well allow
them to configure it to avoid things like IO spikes.

Nathan


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: "bucoo@sohu.com"
Date:
Subject: Re: Re: parallel distinct union and aggregate support patch