On Mon, Oct 30, 2023 at 2:46 PM Andres Freund <and...@anarazel.de> wrote: > After playing with this for a while, I don't see a reason for wal_summarize_mb > from a memory usage POV at least.
Cool! Thanks for testing. > I wonder if there are use cases that might like to consume WAL summaries > before the next checkpoint? For those wal_summarize_mb likely wouldn't be a > good control, but they might want to request a summary file to be created at > some point? It's possible. I actually think it's even more likely that there are use cases that will also want the WAL summarized, but in some different way. For example, you might want a summary that would give you the LSN or approximate LSN where changes to a certain block occurred. Such a summary would be way bigger than these summaries and therefore, at least IMHO, a lot less useful for incremental backup, but it could be really useful for something else. Or you might want summaries that focus on something other than which blocks got changed, like what relations were created or destroyed, or only changes to certain kinds of relations or relation forks, or whatever. In a way, you can even think of logical decoding as a kind of WAL summarization, just with a very different set of goals from this one. I won't be too surprised if the next hacker wants something that is different enough from what this does that it doesn't make sense to share mechanism, but if by chance they want the same thing but dumped a bit more frequently, well, that can be done. -- Robert Haas EDB: http://www.enterprisedb.com
