Re: relfilenode statistics

Hi,

On Fri, Jul 10, 2026 at 03:05:35PM +0900, Michael Paquier wrote:
> - 0003

Thanks for sharing this! Now that the table/index split is (almost) in, let's
focus again on the relfilenode statistics.

> property that I do not wish to keep around is the aggregation of
> counters across rewrites, as the new counters don't make sense once we
> switch to a new relfilenode.

I think we should first agree on this point before looking further at 0003.
As written, the existing pg_stat_all_tables tuple related counters would be reset
by a rewrite.

The concern I see is how these statistics are currently used: relation_needs_vacanalyze()
uses dead_tuples, ins_since_vacuum, and mod_since_analyze for its three tuple based
vacuum or analyze decisions.

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?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com