On Sat, Dec 21, 2024 at 10:28 AM Robert Treat <rob@xzilla.net> wrote:
>
> On Tue, Dec 17, 2024 at 5:51 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> It feels to me like eager vacuums are not so much a distinct thing,
> but that, like how all vacuum do index cleanup unless told not to, all
> vacuums are optimistic that they will convert avp to afp, only we bail
> out quickly if the table is below vacuum_freeze_min_age and we throw
> the limits out if it is above autovacuum_freeze_max_age, similar to
> how we manage vacuum cost limit.
I like this framing/way of thinking about it. v4 in [1] eliminates the
concept of eager vacuums. I still use the aggressive vacuum and
non-aggressive vacuum framing. But, if we add a reloption/GUC to allow
configuring failures per region (proposed in [1]), that means more
using-facing docs and I think this way of framing it as a spectrum of
all-visible page scanning based on relfrozenxid's relationship to each
of these GUCs might be a clear way to explain eager scanning to users.
> In a general sense, you want to know if your vacuums are converting
> avp to afp since it can explain i/o usage. In this version of the
> patch, we know it is turned on based on VacEagerness, but it'd be nice
> to know if it got turned off; ie. basically if we end up in
> if (vacrel->eager_pages.remaining_successes == 0) maybe drop a note in the logs.
I've added a logging message like this.
> In a world where all vacuums are eager vacuums, I think you still want
> the latter messaging, but I think the former would end up being noted
> based on the outcome of criteria in vacuum_get_cutoffs() (primarily if
> we are over the freeze limit).
Hmm. Now that I've eliminated the concept of eager vacuums, users are
not informed whether or not eager scanning is enabled at the beginning
of vacuum. Only when eager scanning is disabled during vacuum or at
the end when they see the number of pages eagerly scanned would they
know whether or not this eager scanning happened.
- Melanie
[1] https://www.postgresql.org/message-id/CAAKRu_byJgf3wB8ukv6caXROReS1SRZsVPb7RWP%2B8qPtdDGykw%40mail.gmail.com
