Re: Count and log pages set all-frozen by vacuum - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Count and log pages set all-frozen by vacuum
Date
Msg-id CAH2-WznyKPPGZ5aoVxRQOhRL6V+BzQcasXUeHfYG9QFQJyYPyw@mail.gmail.com
Whole thread Raw
In response to Re: Count and log pages set all-frozen by vacuum  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Count and log pages set all-frozen by vacuum
List pgsql-hackers
On Thu, Oct 31, 2024 at 11:26 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I'm biased because I want the count of pages newly set all-frozen in
> the VM for another patch. You think exposing the total number of
> all-frozen pages at the end of the vacuum is more useful to users?

The emphasis on the work that one particular VACUUM operation
performed doesn't seem like the most relevant thing to users (I get
why you'd care about it in the context of your work, though). What
matters to users is that the overall picture over time is one where
VACUUM doesn't leave an excessive number of pages
not-all-frozen-in-VM.

What if we're just setting the same few pages all-frozen, again and
again? And what about normal (non-aggressive) VACUUMs that effectively
*increase* the number of pages future aggressive VACUUMs need to scan?
As you well know, by setting some pages all-visible (not all-frozen),
VACUUM essentially guarantees that those same pages can only get
frozen by future aggressive VACUUMs. All these factors seem to argue
for using visibilitymap_count for this (which is not to say that I am
opposed to instrumented pages newly marked all-frozen in the VM, if it
makes sense as part of some much larger project).

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: small pg_combinebackup improvements
Next
From: Robert Haas
Date:
Subject: Re: Count and log pages set all-frozen by vacuum