Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 8 Oct 2024 13:46:23 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: per backend I/O statistics
Message-ID: <ZwS5H5Fu0LnSev90@paquier.xyz>
References: <Ztm811fM73GFt4z/@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZtsZtaRza9bFFeF8@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN55FZ0mnVe4rra2WXca=j+7fabVRY8uhRFPXFmkdRW9J4dKbQ@mail.gmail.com>
 <ZuRjxA+ysI4mpTSq@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN55FZ0_0Fj6No-axtDF-jrPQKh6a-qLoU73mpSAG417D+A-NA@mail.gmail.com>
 <Zul++79EOPsFB+Gd@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN55FZ0xEC6K=EqTwboHJtzZnENDoEwvWOerKkHbZwFT-cU6XQ@mail.gmail.com>
 <ZumKktat4RtHmxL/@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zuz5iQ4AjcuOMx_w@paquier.xyz>
 <ZwOvzX219kDhEEMu@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="CNk3c00+8X2AgAn7"
Content-Disposition: inline
In-Reply-To: <ZwOvzX219kDhEEMu@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/ZwS5H5Fu0LnSev90%40paquier.xyz>
Precedence: bulk


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

On Mon, Oct 07, 2024 at 09:54:21AM +0000, Bertrand Drouvot wrote:
> On Fri, Sep 20, 2024 at 01:26:49PM +0900, Michael Paquier wrote:
>> This would rely on the fact that we would use the ProcNumber for the
>> dshash key, and this information is not provided in pg_stat_activity.
>> Perhaps we should add this information in pg_stat_activity so as it
>> would be easily possible to do joins with a SQL function that returns
>> a SRF with all the stats associated with a given connection slot
>> (auxiliary or backend process)?
>=20
> I'm not sure that's needed. What has been done in the previous versions is
> to get the stats based on the pid (see pg_stat_get_backend_io()) where the
> procnumber is retrieved with something like GetNumberFromPGProc(BackendPi=
dGetProc(pid)).

Ah, I see.  So you could just have the proc number in the key to
control the upper-bound on the number of possible stats entries in the
dshash.

Assuming that none of this data is persisted to the stats file at
shutdown and that the stats of a single entry are reset each time a
new backend reuses a previous proc slot, that would be OK by me, I
guess.

>> The active PIDs of the live sessions are not stored in the active
>> stats, why not?=20
>=20
> That was not needed. We can still retrieve the stats based on the pid tha=
nks
> to something like GetNumberFromPGProc(BackendPidGetProc(pid)) without hav=
ing
> to actually store the pid in the stats. I think that's fine because the p=
id
> only matters at "display" time (pg_stat_get_backend_io()).

Okay, per the above and the persistency of the stats.
--
Michael

--CNk3c00+8X2AgAn7
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmcEuR8ACgkQnvQgOdby
QH0I0Q//QA9kMICf11jNomddXw5sx5CiJyvuHPmRX97X1b1EjoqEPPFhumnHUnii
nZ/D/tjLXNbce1GgcqygDiXurSn/z+lfDPaTmTXWWhBeC0KRWjXMiasbfOjIiw4z
H1hhAwPxaaGxLFcz4j6xMmVa6Bk3wvy2jZ0iKJ/21251nJfows7yVYQPAxUbMiUV
ONnApe/lOix+1in25iuck8vX1KaJ0WOVLUhTKUZEu/7L5Mo7XMOX5CgonJm+mpV8
fbNgBZPEFdr2fNB4jRa6zQagbOro2bXvooFwwmrd7zm1eQNS744GYBeSVVgTwj05
YRni8W7QPJgWHEbURvlyj2ixJdRhlkhl/jJplJAkBTHU7Ulp2qRBCNHPY/KxKK0d
eFrVszPKwxuR12I4ZyRy395b27AhL1tROCSKhSVOoZf+zgZSvSt7UAASaylopVW+
GdicETNmdJUEU4OvF0W4mbZny8A6esNowhaSNrjy9nUDRMIBhqTCrRraieIF+8Ps
rl417ceYk5LH5r9J51YTLP2mWj4p2YUAb3D6tIoWojeu4INKCkiZO/W2+Npn5zs+
88sDjbCEcJ8AWgWAXjI1tUOXsgEfID561HqL6jMtaMZ/wKGziMYLGHg/TsmMxhYD
21qCw4e0dI0II0S+T+e/Ay+98u0q8z46aydXRG6mrH0Kb6/NX+8=
=DaP/
-----END PGP SIGNATURE-----

--CNk3c00+8X2AgAn7--