Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 10 Jul 2024 15:02:34 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <Zo4j-mC0Ps3vnjZ4@paquier.xyz>
References: <ZlGYokUIlERemvpB@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="tmxuB7aoL5XaddBi"
Content-Disposition: inline
In-Reply-To: <ZlGYokUIlERemvpB@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/Zo4j-mC0Ps3vnjZ4%40paquier.xyz>
Precedence: bulk


--tmxuB7aoL5XaddBi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, May 25, 2024 at 07:52:02AM +0000, Bertrand Drouvot wrote:
> But I think that it is in a state that can be used to discuss the approach it
> is implementing (so that we can agree or not on it) before moving
> forward.

I have read through the patch to get an idea of how things are done,
and I am troubled by the approach taken (mentioned down by you), but
that's invasive compared to how pgstats wants to be transparent with
its stats kinds.

+   Oid         objoid;         /* object ID, either table or function
or tablespace. */
+   RelFileNumber relfile;      /* relfilenumber for RelFileLocator. */
 } PgStat_HashKey;

This adds a relfilenode component to the central hash key used for the
dshash of pgstats, which is something most stats types don't care
about.  That looks like the incorrect thing to do to me, particularly
seeing a couple of lines down that a stats kind is assigned so the
HashKey uniqueness is ensured by the KindInfo:
+   [PGSTAT_KIND_RELFILENODE] = {
+       .name = "relfilenode",

FWIW, I have on my stack of patches something to switch the objoid to
8 bytes, actually, which is something that would be required for
pg_stat_statements as query IDs are wider than that and affect all
databases, FWIW.  Relfilenodes are 4 bytes, okay still Robert has
proposed a couple of years ago a patch set to bump that to 56 bits,
change reverted in a448e49bcbe4.  The objoid is also not something
specific to OIDs, see replication slots with their idx for example.

What you would be looking instead is to use the relfilenode as an
objoid and keep track of the OID of the original relation in each
PgStat_StatRelFileNodeEntry so as it is possible to know where a past
relfilenode was used?  That makes looking back at the past relation's
elfilenodes stats more complicated as it would be necessary to keep a
list of the past relfilenodes for a relation, as well.  Perhaps with
some kind of cache that maintains a mapping between the relation and
its relfilenode history?
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmaOI/oACgkQnvQgOdby
QH3pdBAAnJskDbuUzrXtQHhgIXIzKDpIUcqfmWizS+fWeiRcjk2t4hepNYofdkAq
XRfsBp92xdBMQMpGaNSEGBeLVdPqJo/wGq4VEPALD0ekEVe7wBQvE/oHS9CmMX44
H2QKPOksYqABccmR7cSWuVD3/nOGgKQbo/L/qDKwP4P2sV33FS26x02QqzJCdBh+
wBgzL4xeuKfSxRW43R9sRj8xzx/7gNp5KUc+VtZ4j0Fn9vsIOF9HSbqA/BcV/kT5
kayyTRrgzRgHktF0aLBOjfPin2kS2rscz0K9o+DEFKsm4dlJ+5/Zmi17puUvcwwh
PDCrFhto7xgItVMqEqmtJOtE0Iwn/kOKyRyNqXEyLiY1kM8L5pHhHGFcRcjLLM4T
stHlRv+d//YVJE9Hqqn3F9vBJij3WQ3ZeryR36CSsGtogOddLR5vPjrxADC6xrBu
61WaPjAjpfMF9YiUW+KHzj2iCnEm4sicp477ACIOQ97Kees8MMIYmo43JDLgAsrW
g3p95lZBV0L115Zds1gA4mb/s9zTjPZwBhwPLxUxrkTA10HvBJq5Uolxt/fco3dL
Q26Yyr0VNAwfwKK6Mk2CXJ1yBWegVdREwIFQb7gY8H7IFmrApH78EQ2eHIx0taqO
S4/yZMSazjCE7d9xtLw7WDKyJDRw+cQ4+9qWXlJS3DFYa0p0H8s=
=9jER
-----END PGP SIGNATURE-----

--tmxuB7aoL5XaddBi--