Date: Wed, 1 Oct 2025 14:33:11 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <aN07p71KNFR2HdaD@ip-10-97-1-34.eu-west-3.compute.internal>
References: <Zym1xlMhuzPdekMt@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPhQyvK_wsvV+HiQcC6f57Zg2WO60wxv=CXbcoZ1p5HHEQ@mail.gmail.com>
 <Z0nbomp2e/L30WDA@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPhFaLEWXG9Mn8-tZoS68rE52647a2oZ6jrUNSBtwadD0A@mail.gmail.com>
 <Z07d850Yp7Sd9Qqq@ip-10-97-1-34.eu-west-3.compute.internal>
 <Z3gN3bwUMijyV4I0@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPh76=ACN=z68oM44ZMgZsQxTTYVF8qvi1F6TGA5Mn6uiQ@mail.gmail.com>
 <aMkHSeitgUPtMyA2@paquier.xyz>
 <aNutZbziBycskOYR@ip-10-97-1-34.eu-west-3.compute.internal>
 <aNxiLG0JTCYnpqx6@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aNxiLG0JTCYnpqx6@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/aN07p71KNFR2HdaD%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

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