Re: relfilenode statistics

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.

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? 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.
--
Michael