On Wed, Dec 28, 2022 at 07:03:29PM -0800, Andres Freund wrote:
> Separately I wonder if it's worth micro-optimizing vac_update_datfrozenxid() a
> bit. I e.g. see a noticable speedup bypassing systable_getnext() and using
> heap_getnext(). It's really too bad that we want to check for "in the future"
> xids, otherwise we could use a ScanKey to filter at a lower level.
Another thing I'm exploring is looking up the datfrozenxid/datminmxid
before starting the pg_class scan so that the scan can be stopped early if
it sees that we cannot possibly advance the values. The
overwrite-corrupt-values logic might make this a little more complicated,
but I think it'd be sufficient to force the pg_class scan to complete if we
ever see a value "in the future." Overwriting the corrupt value might be
delayed, but it would eventually happen once the table ages advance.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com