On Fri, Jul 28, 2023 at 3:27 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > I see. I don't have an opinion on the "best of a bad situation" > argument. Though, I think it is worth amending the comment in the code > to include this explanation.
I think that the user-facing docs should be completely overhauled to make that clear, and reasonably accessible. It's hard to talk about in code comments because it's something that can only be effective over time, across multiple VACUUM operations. > But, ISTM that there should also be some independent heuristic to > determine whether or not it makes sense to freeze the page. That could > be related to whether or not it will be cheap to do so (in which case > we can check if we will have to emit an FPI as part of the freeze > record) or it could be related to whether or not the freezing is > likely to be pointless (we are likely to update the page again soon). It sounds like you're interested in adding additional criteria to trigger page-level freezing. That's something that the current structure anticipates. To give a slightly contrived example: it would be very easy to add another condition, where (say) we call random() to determine whether or not to freeze the page. You'd very likely want to gate this new trigger criteria in the same way as the FPI criteria (i.e. only do it when "prunestate->all_visible && prunestate->all_frozen" hold). We've decoupled the decision to freeze from what it means to execute freezing itself. Having additional trigger criteria makes a lot of sense. I'm sure that it makes sense to add at least one more, and it seems possible that adding several more makes sense. Obviously, that will have to be new work targeting 17, though. I made a decision to stop working on VACUUM, though, so I'm afraid I won't be able to offer much help with any of this. (Happy to give more background information, though.) -- Peter Geoghegan