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
