On Tue, Jul 5, 2022 at 11:09 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> Actually, I was wrong. I thought that we only mentioned that we
> computed a more agressive xid, but now see I was mentioning the _frozen_
> xid. Reading the commit, we do compute the multi-xid and store that too
> so I have updated the PG 15 release notes with the attached patch.
It might be worth using the "symbol names" directly, since they appear
in the documentation already (under "Routine Vacuuming"). These are
<structfield>relfrozenxid</structfield> and
<structfield>relminmxid</structfield>. These are implementation
details, but they're documented in detail (though admittedly the
documentation has *lots* of problems).
Here is what I would like this item to hint at, to advanced users with
tricky requirements: The new approach to setting relminmxid will
improve the behavior of VACUUM in databases that already happen to use
lots of MultiXacts. These users will notice that autovacuum now works
off of relminmxid values that actually tell us something about each
table's consumption of MultiXacts over time. Most individual tables
naturally consume *zero* MultiXacts, even in databases that consume
many MultiXacts -- due to naturally occuring workload characteristics.
The old approach failed to recognize this, leading to very uniform
relminmxid values across tables that were in fact very different,
MultiXact-wise.
The way that we handle relfrozenxid is probably much less likely to
make life much easier for any database, at least on its own, in
Postgres 15. So from the point of view of a user considering
upgrading, the impact on relminmxid is likely to be far more
important.
Admittedly the most likely scenario by far is that the whole feature
just isn't interesting, but a small minority of advanced users (users
with painful MultiXact problems) will find the relminmxid thing very
compelling.
--
Peter Geoghegan