Re: pgsql: Don't consider newly inserted tuples in nbtree VACUUM.

Hi Peter,

On Thu, Mar 11, 2021 at 12:27:25AM +0000, Peter Geoghegan wrote:
> The vacuum_cleanup_index_scale_factor/stats interface made the nbtree AM
> partially responsible for deciding when pg_class.reltuples stats needed
> to be updated. This seems contrary to the spirit of the index AM API,
> though -- it is not actually necessary for an index AM's bulk delete and
> cleanup callbacks to provide accurate stats when it happens to be
> inconvenient. The core code owns that. (Index AMs have the authority
> to perform or not perform certain kinds of deferred cleanup based on
> their own considerations, such as page deletion and recycling, but that
> has little to do with pg_class.reltuples/num_index_tuples.)

I think that this commit has some issues that need more thoughts.

The removal of vacuum_cleanup_index_scale_factor means that any
existing deployment of Postgres that includes at least one index using
this parameter would fail in the middle of the restore during
pg_upgrade, when restoring the binary dump. It seems to me that it is
user-unfriendly to complain in the middle of an upgrade, as it could
take time before being detected. In my opinion, it would be better to
do something else. Here are three possibilities:
1) Make pg_upgrade check at its beginning if any databases to upgrade
include an index with this parameter set.
2) Tweak the upgrade/restore to ignore this parameter if set.
3) Let the option live in the existing set of relation options, but
just ignore it in the backend code.

On top of that, you have a second issue here: a pg_dump from 14
dumping from an older server would also happily dump any indexes with
this parameter set, making the dump incompatible with 14.

Thanks,
--
Michael