On 11/28/20, 9:50 AM, "Stephen Frost" <sfr...@snowman.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
