Re: relfilenode statistics

Hi,

On Wed, Oct 01, 2025 at 08:05:16AM +0900, Michael Paquier wrote:
> On Tue, Sep 30, 2025 at 10:13:57AM +0000, Bertrand Drouvot wrote:
> > As far Michael's concern about adding a new field in the hash key, as 8 bytes
> > is allocated for the object ID, then we can go with:
> > 
> > dboid (linked to RelFileLocator's dbOid)
> > objoid (linked to RelFileLocator's spcOid and to the RelFileLocator's relNumber)
> > 
> > and avoid adding a new field in the key.
> 
> RelFileNumber is a 4-byte Oid, so this mapping should be able to work.

Right.

> Is there any reason why you would want an efficient filtering of the
> contents of the shared hashtable based only on a relnumber or a
> tablespace OID?

Not that I can think of currently.

> Perhaps yes, like when a relfilenode is dropped into
> a bin for an efficient removal from the shared hashtable so as we
> don't need to do a seqscan, I just don't remember all the details of
> the patch and if it could act as a bottleneck in some scenarios.

I think the first step is to replace (i.e get rid) PGSTAT_KIND_RELATION by a brand
new PGSTAT_KIND_RELFILENODE and move all the existing stats that are currently
under the PGSTAT_KIND_RELATION to this new PGSTAT_KIND_RELFILENODE.

Let's do this by keeping the pg_stat_all_tables|indexes and pg_statio_all_tables|indexes
on top of the PGSTAT_KIND_RELFILENODE and ensure that a relation rewrite keeps 
those stats. Once done, we could work from there to add new stats (add writes
counters and ensure that some counters (n_dead_tup and friends) are replicated).

Does that make sense to you?

Regards,

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