Re: pgsql: Add VACUUM instrumentation for scanned pages, relfrozenxid. - Mailing list pgsql-committers

From Peter Geoghegan
Subject Re: pgsql: Add VACUUM instrumentation for scanned pages, relfrozenxid.
Date
Msg-id CAH2-Wz=8eacEbE_WhB87SkVw1LktjY5jX27wEVF3pf0jHUGaDQ@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Add VACUUM instrumentation for scanned pages, relfrozenxid.  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-committers
On Wed, Sep 14, 2022 at 1:20 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> According to the surrounding math in each case, this means that the new
> %u is larger by %d than the previous value.
>
> The use of "ahead of" had confused me here, since I needed to think
> three times about which direction is meant.  I suppose it's technically
> correct, but perhaps there is a clearer term?

I don't know. There are several things to consider here. Or at least
several things that I've considered, that seem important. These are:

* We kinda need to "hide" the original relfrozenxid from the user
(just show the new one) by just showing a delta. After all, we might
needlessly confuse users if we ended up showing an original
relfrozenxid that has been advanced to a more recent value that is
ostensibly (though not actually) far older than the original.

Most users won't quite understand that XIDs use modulo-2^32
arithmetic. It isn't actually important that they understand the
details, so I really would rather not go there.

* The delta is very useful for comparing successive VACUUM operations
for the same table (usually a very large table) over time.

The dimension of time is very important -- how things change for the
table (this is true for everything, not just relfrozenxid stuff). The
XIDs themselves aren't terribly meaningful over time (they get
recycled), but the XID-age-wise deltas really can be compared to each
other easily and sensibly. The variance of the "advanced by this many
XIDs" delta over time might be very interesting.

I expect that this will become much more important in Postgres 16.
It's much easier for VACUUM to find a way to keep up over time if it
is given breathing room to freeze when it's easiest/cheapest. We'll
still have to insist on keeping relfrozenxid recent at some point, but
doing so prematurely seems very counterproductive to me.

* The delta thing also highlights the relationship between "removable
cutoff" and its own XID age at the end of the VACUUM, which is itself
a delta.

The maximum final relfrozenxid that can ever be set by VACUUM is also
"removable cutoff". ISTM that there is value in hinting at that
relationship through how we present the information. It's something
that advanced users have a good chance of picking up on if they see
lots of examples of.

-- 
Peter Geoghegan



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Doc: add some doco about using the libpq_pipeline test module.
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Move gramparse.h to src/backend/parser