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
