On Wed, Sep 27, 2023 at 5:20 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > > Can you define "unfreeze"? I don't know if this newly invented term > > refers to unsetting a page that was marked all-frozen following (say) > > an UPDATE, or if it refers to choosing to not freeze when the option > > was available (in the sense that it was possible to do it and fully > > mark the page all-frozen in the VM). Or something else. > > By "unfreeze", I mean unsetting a page all frozen in the visibility > map when modifying the page for the first time after it was last > frozen.
I see. So I guess that Andres meant that you'd track that within all backends, using pgstats infrastructure (when he summarized your call earlier today)? And that that information would be an important input for VACUUM, as opposed to something that it maintained itself? > I would probably call choosing not to freeze when the option is > available "no freeze". I have been thinking of what to call it because > I want to add some developer stats for myself indicating why a page > that was freezable was not frozen. I think that having that sort of information available via custom instrumentation (just for the performance validation side) makes a lot of sense. ISTM that the concept of "unfreezing" a page is equivalent to "opening" the page that was "closed" at some point (by VACUUM). It's not limited to freezing per se -- it's "closed for business until further notice", which is a slightly broader concept (and one not unique to Postgres). You don't just need to be concerned about updates and deletes -- inserts are also a concern. I would be sure to look out for new inserts that "unfreeze" pages, too -- ideally you'd have instrumentation that caught that, in order to get a general sense of the extent of the problem in each of your chosen representative workloads. This is particularly likely to be a concern when there is enough space on a heap page to fit one more heap tuple, that's smaller than most other tuples. The FSM will "helpfully" make sure of it. This problem isn't rare at all, unfortunately. > > The choice to freeze or not freeze pretty much always relies on > > guesswork about what'll happen to the page in the future, no? > > Obviously we wouldn't even apply the FPI trigger criteria if we could > > somehow easily determine that it won't work out (to some degree that's > > what conditioning it on being able to set the all-frozen VM bit > > actually does). > > I suppose you are thinking of "opportunistic" as freezing whenever we > aren't certain it is the right thing to do simply because we have the > opportunity to do it? I have heard the term "opportunistic freezing" used to refer to freezing that takes place outside of VACUUM before now. You know, something perfectly analogous to pruning in VACUUM versus opportunistic pruning. (I knew that you can't have meant that -- my point is that the terminology in this area has problems.) > I want a way to express "freeze when freeze min age doesn't require it" That makes sense when you consider where we are right now, but it'll sound odd in a world where freezing via min_freeze_age is the exception rather than the rule. If anything, it would make more sense if the traditional min_freeze_age trigger criteria was the type of freezing that needed its own adjective. -- Peter Geoghegan
