Re: Eager page freeze criteria clarification

On Fri, Jul 28, 2023 at 4:49 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Fri, Jul 28, 2023 at 4:30 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > Put differently, I can't see any reason to care whether pruning
> > > emitted an FPI or not. Either way, it's very unlikely that freezing
> > > needs to do so.
> >
> > +many
> >
> > Using FPIs having been generated during pruning as part of the logic to decide
> > whether to freeze makes no sense to me. We likely need some heuristic here,
> > but I suspect it has to look quite different than the FPI condition.
>
> I think that it depends on how you frame it. It makes zero sense that
> that's the only thing that can do something like this at all. It makes
> some sense as an incremental improvement, since there is no way that
> we can lose by too much, even if you make arbitrarily pessimistic
> assumptions. In other words, you won't be able to come up with an
> adversarial benchmark where this loses by too much.

When you were working on this, what were the downsides of only having the
criteria that 1) page would be all_visible/all_frozen and 2) we did prune
something (i.e. no consideration of FPIs)?

> As I said, I'm no longer interested in working on VACUUM (though I do
> hope that Melanie or somebody else picks up where I left off). I have
> nothing to say about any new work in this area. If you want me to do
> something in the scope of the work on 16, as a release management
> task, please be clear about what that is.

I'm only talking about this in the context of future work for 17.

- Melanie