On Mon, Aug 28, 2023 at 5:06 PM Peter Geoghegan <p...@bowt.ie> wrote: > > On Mon, Aug 28, 2023 at 1:17 PM Robert Haas <robertmh...@gmail.com> wrote: > > I'm sure this could be implemented, but it's unclear to me why you > > would expect it to perform well. Freezing a page that has no frozen > > tuples yet isn't cheaper than freezing one that does, so for this idea > > to be a win, the presence of frozen tuples on the page would have to > > be a signal that the page is likely to be modified again in the near > > future. In general, I don't see any reason why we should expect that > > to be the case. > > What I've described in a scheme for deciding to not freeze where that > would usually happen -- a scheme for *vetoing* page freezing -- rather > than a scheme for deciding to freeze. On its own, what I suggested > cannot help at all. It assumes a world in which we're already deciding > to freeze much more frequently, based on whatever other criteria. It's > intended to complement something like the LSN scheme.
I like the direction of this idea. It could avoid repeatedly freezing a page that is being modified over and over. I tried it out with a short-running version of workload I (approximating a work queue) -- and it prevents unnecessary freezing. The problem with this criterion is that if you freeze a page and then ever modify it again -- even once, vacuum will not be allowed to freeze it again until it is forced to. Perhaps we could use a very strict LSN cutoff for pages which contain any frozen tuples -- for example: only freeze a page containing a mix of frozen and unfrozen tuples if it has not been modified since before the last vacuum of the relation ended. - Melanie
