On Thu, Aug 13, 2026 at 08:09:25AM +0000, Bertrand Drouvot wrote: > For example, a SET TABLESPACE move allocates a new relfilenumber but only > copies > the relation’s storage. The previous counters are not transferred, so they are > read as zero for the new relfilenumber. A table that was eligible for vacuum > or > analyze before the move may therefore no longer be eligible. > > Do you agree that rewrites should not reset these counters?
If the new relfilenode is completely rewritten, where the past stats don't really make much sense, mostly resetting them makes sense. One thing I am wondering, though, would be to make sure that the stats are correctly updated after the rewrite. In most cases, that would be mostly to track that we have a correct number of tuples inserted, as tablecmds.c should do rewrites with bulk inserts after deconstructing the data (like TOAST blobs in some cases). Cases like SET TABLESPACE are indeed worth bothering about: we don't rewrite a new relfilenode, just copy it over to the new tablespace while keeping the original one intact, because it's cheaper. In this case keeping the previous stats would make sense because they reflect the existing on-disk state. Now that I look at it, I am pretty sure that my previous POC embryon patch is not doing that correctly. -- Michael
signature.asc
Description: PGP signature
