Re: Instrumented pages/tuples frozen in autovacuum's server log out (and VACUUM VERBOSE) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Instrumented pages/tuples frozen in autovacuum's server log out (and VACUUM VERBOSE)
Date
Msg-id CAH2-WzkdV_+vXKYebaBDsAzuBB_=OOEwCemuSKBSn7cEEhVJLg@mail.gmail.com
Whole thread Raw
In response to Re: Instrumented pages/tuples frozen in autovacuum's server log out (and VACUUM VERBOSE)  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Wed, Aug 31, 2022 at 7:49 PM Jeff Janes <jeff.janes@gmail.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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types
Next
From: Amit Kapila
Date:
Subject: Re: Handle infinite recursion in logical replication setup