Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 1 Oct 2025 08:05:16 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <aNxiLG0JTCYnpqx6@paquier.xyz>
References: 
 <CA+TgmoZtRxvAuMyO4bQjj5t47XWvQsowPAedkOkrCP61B7mQFg@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="8ykivmOTu3g4xpEw"
Content-Disposition: inline
In-Reply-To: <aNutZbziBycskOYR@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/aNxiLG0JTCYnpqx6%40paquier.xyz>
Precedence: bulk


--8ykivmOTu3g4xpEw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 b=
ytes
> is allocated for the object ID, then we can go with:
>=20
> dboid (linked to RelFileLocator's dbOid)
> objoid (linked to RelFileLocator's spcOid and to the RelFileLocator's rel=
Number)
>=20
> 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

--8ykivmOTu3g4xpEw
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmjcYiwACgkQnvQgOdby
QH1QbQ/+IwmUhrudNRa77nigYZqqJ0sD8S1IlcFytlWivFlrpk87hclGElYz+Max
UkJvtLmKGeRlwTu9S+HrPWy8SygOvyb9yh6DJgA76rMY9LKL8kV2zm2nKoeyHMaD
czVBcHYSPqaJwMlpu7A7AK5PmOw9DOwyDa9cC47/pWvZ5GLFk2ajQI7BkN8Xw90Q
fe3UmHqU9Al3e51Uw+s5DgT5G3aIcNHT93gh9Z/y+cR2S0FpRsDHk+iQGQ+GeXjs
CtMqVOzRMfLo3ArOeKATjLQ7RK6YksU+6FE3lyhoFtlrr2qBAjkryaV1vFYeO8pH
jFjgbvZLCTPAAtrdh+m6xDZP5jF/udkMCxcHwcB1c9zFQ29Ee+GOi7hbcd0W8/qp
34i8pigJHHiCt4cAzeIN9fkD4fuYrJIhA7kmIFGFFkboy+o1bmD6tE//lUI/u/Bh
513JNLRhFRbzVmN/Hv9OrDs9j2JaQaNz2ofoylibkk1fbExwLmdNcFzTWzBgGd0e
J7amntvDBCaCU48RzH2q1ch5T5EZ7P24i9KFu0+0Dq0icY/04ZOFFA94Il+cotZu
NlU4Eg2U9q21h0QfwW55YOWWbNB6eaQQdFQeWMyqeY6n9clKqFvmwB4ETPzh5IhC
SXJZ7fH3GBR+RCFiT4e8Pb/8b9hWAGTWpIXZ3ZPcENvUABxUtZI=
=VdbK
-----END PGP SIGNATURE-----

--8ykivmOTu3g4xpEw--