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
