Re: Instrumented pages/tuples frozen in autovacuum's server log out (and VACUUM VERBOSE)

On Wed, Aug 31, 2022 at 7:49 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> I like this addition, but I would also like to see how many pages got newly set to all frozen by the vacuum.

I'd say that that's independent work. Though I'm happy to discuss it now.

It would be fairly straightforward to show something about the VM
itself, but it's not entirely clear what aspects of the VM should be
emphasized. Are we reporting on the state of the table, or work
performed by VACUUM? You said you were interested in the latter
already, but why prefer that over a summary of the contents of the VM
at the end of the VACUUM? Are you concerned about the cost of setting
pages all-visible? Do you have an interest in how VACUUM manages to
set VM pages over time? Something else?

We already call visibilitymap_count() at the end of every VACUUM,
which scans the authoritative VM to produce a more-or-less consistent
summary of the VM at that point in time. This information is then used
to update pg_class.relallvisible (we don't do anything with the
all-frozen number at all). Why not show that information in
VERBOSE/autovacuum's log message? Does it really matter *when* a page
became all-visible/all-frozen/unset?

> Also, isn't all of vacuuming about XID processing? I think "frozen:" would be a more suitable line prefix.

That also works for me. I have no strong feelings here.

--
Peter Geoghegan