On Tue, Dec 13, 2022 at 9:16 AM Peter Geoghegan <p...@bowt.ie> wrote: > That's not the only thing we care about, though. And to the extent we > care about it, we mostly care about the consequences of either > freezing or not freezing eagerly. Concentration of unfrozen pages in > one particular table is a lot more of a concern than the same number > of heap pages being spread out across multiple tables. Those tables > can all be independently vacuumed, and come with their own > relfrozenxid, that can be advanced independently, and are very likely > to be frozen as part of a vacuum that needed to happen anyway.
At the suggestion of Jeff, I wrote a Wiki page that shows motivating examples for the patch series: https://wiki.postgresql.org/wiki/Freezing/skipping_strategies_patch:_motivating_examples These are all cases where VACUUM currently doesn't do the right thing around freezing, in a way that is greatly ameliorated by the patch. Perhaps this will help other hackers to understand the motivation behind some of these mechanisms. There are plenty of details that only make sense in the context of a certain kind of table, with certain performance characteristics that the design is sensitive to, and seeks to take advantage of in one way or another. -- Peter Geoghegan
