From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: Eager page freeze criteria clarification |
Date: | 2023-07-28 20:49:04 |
Message-ID: | CAH2-Wzk7XnFPFynYQOa5F+=yp+YQndqaT63bBBoJzfp3d_V3Bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-07-28 20:49:43 | Re: Eager page freeze criteria clarification |
Previous Message | Andres Freund | 2023-07-28 20:34:15 | Re: Support worker_spi to execute the function dynamically. |