Re: relfilenode statistics

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