Hi, On Tue, Dec 16, 2025 at 04:33:17PM +0900, Michael Paquier wrote: > > Hence, why don't we split PgStat_StatTabEntry into three things from > the start, even if it means to duplicate some of them? Say: > - Table fields: includes [auto]vacuum/analyze data, block fields, > fields of pg_stat_all_tables. > - Index fields: no need for the [auto]vacuum/analyze time and counts, > block fields, pg_stat_all_indexes fields. > - Relfilenode fields: dead_tuples, ins_since_vacuum and > mod_since_analyze. Does not apply to partitioned tables and indexes, > only applies to tables. Provides a clean split, embrace the fact that > these are the only three fields we need to worry about during > recovery.
I think that the PSEUDO_PARTITION_TABLE_SPCOID just proposed in [1] approach is simple enough and solves the collision issue raised by Andres. I think I prefer the unified structure as proposed in the patch (though we may want to split tables and indexes later on). The reason is that it's easier to expose publicly. Indeed, at the very beginning of this thread, in v1, I created a new PGSTAT_KIND_RELFILENODE and had to make it coexist with PGSTAT_KIND_RELATION and that led to discussion on how we should expose them ([2]). [1]: https://www.postgresql.org/message-id/aUEyzoOJtrCLAEeT%40ip-10-97-1-34.eu-west-3.compute.internal [2]: https://www.postgresql.org/message-id/CA%2BTgmoZtwT6h%3DnyuQ1J9GNSrRyhf0fv7Ai6FzO%3DbH0C9Bf6tew%40mail.gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
