Re: relfilenode statistics

On Mon, Mar 09, 2026 at 07:43:43AM +0000, Bertrand Drouvot wrote:
> PFA, a new mandatory rebase.

So, we have discussed that a couple of days ago offline, and I still
felt uncomfortable to not do a cleanup of the relation stats data for
indexes. A lot of the fields are stored in memory and written in the
file, and remain unused for indexes.

So, please find attached a patch set demonstrating the ideas I had on
the matter:
- 0001 refactors PgStat_StatTabEntry so as the data for indexes and
tables is split. The advantage of this one is a reduction of the
shared memory usage, as most of the fields of PgStat_StatTabEntry are
not used for indexes. These are hidden behind a new stats kind.
That's only refactoring, no changes. If you look closely, you would
notice this one:
+ .pending_size = sizeof(PgStat_TableStatus),
While weird in itself, that links to a problem addressed by 0002
related to the handling of pending data.
- 0002 reworks the way we store pending data, for the transactional
and non-transactional bits, as indexes don't care about the
transactional parts. PgStat_TableStatus is renamed, refactored so as
the table and index parts are split into two. That finishes the split
of both stats kinds, preparing for the next patch with the
introduction of relfilenode stats.
- 0003, super WIP, that I am happy to share based on the fact that it
is able to populate the stats entries at replay (tested quickly a few
replay scenarios, seems to basically work). Now, while it passes
check-world, this patch has various issues that I did not look much
into yet (lack of time), but it shows the idea. Note that "get"
functions do a direct lookup at the relfilenode, implying
modifications in the views to rely on pg_relation_filenode().
Perhaps we should do things the other way around, where we still pass
an OID but look at the relation mapper for shared catalogs each time
one of these functions is called. This has the effect to replace the
various "get" functions to some "relfilenode/rfn" flavors, that can
get the fields directly by getting a relfilenode in input. One
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'm feeling the right amount of interface in 0001. 0002 is also quite
nice after some time looking at it. 0003 needs a lot more work to be
presentable; the basics are surely interesting to see done this way.
Comments and thoughts are welcome.
--
Michael