Re: A few new options for CHECKPOINT

On 11/28/20, 9:50 AM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
>> Granted, I used a rather aggressive checkpoint_timeout, but I think
>> this demonstrates that waiting for a non-immediate checkpoint to
>> complete can lower the amount of WAL needed for recovery, even though
>> it might not lower it as much as waiting for an immediate checkpoint
>> would.
>
> The difference here feels like order of magnitudes to me, between an
> immediate checkpoint and a non-immediate one, vs. a much smaller
> difference as you've shown here (though, still, kill'ing the postmaster
> isn't exactly the same as what your patch would be doing, so I don't
> really like using this particular analysis to answer this question...).

I agree that using an immediate checkpoint is the best for reducing
recovery time. IMO reducing the amount of WAL to recover by up to 50%
from doing no checkpoint at all is also a reasonable use case,
especially if avoiding an IO spike is important.

> If the use-case here was just that you wanted to add more options to the
> CHECKPOINT command because we have them internally and maybe they'd be
> useful to expose then these things probably wouldn't matter so much, but
> to imply that this is really going to cut down on the amount of WAL
> replay required a lot isn't really coming through even with these
> results.

This is how I initially presented this patch. I only included this
use case because I was asked for concrete examples of how it might be
useful.

Nathan