Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 23 Jan 2025 17:05:30 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Subject: Re: per backend WAL statistics
Message-ID: <Z5H4Su2fvuRD82dl@paquier.xyz>
References: <Z4BmdUQQh8jzlPHq@paquier.xyz>
 <Z4DrFhdlO6Xf13Xd@ip-10-97-1-34.eu-west-3.compute.internal>
 <Z4dRlNuhSQ3hPPv2@paquier.xyz>
 <Z4ks4+wnAz8eEyX9@ip-10-97-1-34.eu-west-3.compute.internal>
 <xibh465r3x7xvpzaozu47fxule3dktvwz4yacce4pjlw76lkjd@fjvm56zbev37>
 <Z4k9rb3aTNVSmyq/@ip-10-97-1-34.eu-west-3.compute.internal>
 <aj5vdgpbux5e2dbr6gcgd4eu3krjrflljt2neivh2vbkfrlant@2qedfymz7lmh>
 <Z4mZvW9ugvCOd_QH@paquier.xyz>
 <Z49KmyAIFQtDp0bV@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="FPDGd6js2iQrp5iY"
Content-Disposition: inline
In-Reply-To: <Z49KmyAIFQtDp0bV@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/Z5H4Su2fvuRD82dl%40paquier.xyz>
Precedence: bulk


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

On Tue, Jan 21, 2025 at 07:19:55AM +0000, Bertrand Drouvot wrote:
> PFA v6 that now relies on the new PendingBackendStats variable introduced=
 in
> 4feba03d8b9.
>=20
> Remark: I moved PendingBackendStats back to pgstat.h because I think that=
 the
> "simple" pending stats increment that we are adding in xlog.c are not wor=
th
> an extra function call overhead (while it made more sense for the more co=
mplex IO
> stats handling). So PendingBackendStats is now visible to the outside wor=
ld like
> PendingWalStats and friends.

You are re-doing here a pattern I was trying to avoid so as we don't
copy-paste more checks based on pgstat_tracks_backend_bktype more than
necessary.  I am wondering if we should think harder about the
interface used to register WAL stats, and make it more consistent with
the way pg_stat_io is handled, avoiding the hardcoded attribute
numbers if we have an enum to control which field to update in some
input routine.

As we have only five counters in PgStat_PendingWalStats, the result
you have is not that invasive, true.

Are you sure that the interactions between pgWalUsage, prevWalUsage
and prevBackendWalUsage are correct?  As far I got it from a code
read, prevWalUsage, prevBackendWalUsage and their local trackings in
pgstat_backend.c and pgstat_wal.c rely on instrument.c as the primary
source, as pgWalUsage can never be reset.  Is that right?
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmeR+EoACgkQnvQgOdby
QH3aUQ//f8PlW+fq60OlZDa1AmlLZpZjFo/COdj7S2u5n9zUeN42SDwPvUzyvCr2
hsyvF438BbNFSTU6F2RkUavIOpb/6nszDm8kV5o3sK7RqM5kbOZvvCSvndGJ2QMo
1avAqRHEKd+P7dxo7nGO+dMGXrqk6qXq5tCEOS/FSSeb9/H2h3BLeSMw8a6I6qDp
6vMOlmURBp+MNNIYk3Nc21U5e9T941aKt7/R2S6uBUYlAsZBtgBj9Dnglzu60BRd
F4lZkWPQ0E2XZakk4jIvB3axfobvFYO1rV4+3hffJ2dA8I1Mca1Lo+dY52XsqWwD
2KcJjSSe6DDHOgEUy8+uAVAuJRAvFT+BjkTfZ3470DxruTuTUCcC0N9wsqusCU1G
lih15SBTN73rltHGjSkmv7oxGPGvjVWyCEbpygw/sZLvZwOnPyjzHrEhGq5dEIZg
0o3SZSW1cxcdUKC+iP9bwqRLY4q5U0txELXqsbZIq/JDJyPzauPqtZKgGr2fKwSS
LAfAiSEoePYbhwJQDkwbpotcVjY/np8hI1lzgKMuDBnNdYTlEjbOKr0YpkU9aTW0
CNVkHMxVj/IIS2hpXHGR98JlrLLhFuW0dC0EKdHbkJk1+yFyuFvMVgel+IPUcT7/
aEsK1F0R1czNq2CfPo352TuwLcB85DkONzGS0zUW3vrmMFzTiAE=
=Xqhi
-----END PGP SIGNATURE-----

--FPDGd6js2iQrp5iY--