Re: relfilenode statistics

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