Re: A few new options for CHECKPOINT
От | Bossart, Nathan |
---|---|
Тема | Re: A few new options for CHECKPOINT |
Дата | |
Msg-id | 3785B778-9FED-43DF-B543-64FC88A35823@amazon.com обсуждение исходный текст |
Ответ на | Re: A few new options for CHECKPOINT (Stephen Frost <sfrost@snowman.net>) |
Список | 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 по дате отправления: