On Wed, Jan 26, 2022 at 3:46 PM Greg Stark <st...@mit.edu> wrote: > One thing I've been wanting to do something about is I think > autovacuum needs to be a little cleverer about when *not* to vacuum a > table because it won't do any good.
There was a thread about this exact thing not too long ago: https://postgr.es/m/CAH2-Wzmx6+PrfpmmFw8JZbxD+kkwhQWPOhE5RUBy6S4_Jwty=q...@mail.gmail.com If everything goes according to plan, then Postgres 15 will have my work on freezing and dynamically advancing relfrozenxid. Meaning that you'll be able to see (in autovacuum log output and in VACUUM VERBOSE output) how much relfrozenxid has been advanced by, if at all. You'll also directly see how far behind the VACUUM operation's OldestXmin that is (and how far behind the OldestXmin is at the end of the VACUUM operation). It seems as if this offers you exactly what you need. You'll be able to notice the inherent futility of an anti-wraparound VACUUM that runs against a table whose relfrozenxid is already exactly equal to the VACUUM's OldestXmin (say because of a leaked replication slot -- anything that makes vacuuming fundamentally unable to advance relfrozenxid, really). -- Peter Geoghegan