Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 18 Jul 2024 13:32:48 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Joe Conway <mail@joeconway.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Gurjeet Singh <gurjeet@singh.im>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: RFC: pg_stat_logmsg
Message-ID: <Zpia8GwTB9turihT@paquier.xyz>
References: <89742024-d51a-c66b-90b9-67f837072cd2@joeconway.com>
 <CAD21AoAyPVYZ_6VAQCOanvHTL3CRSqTDCFrtvaYVGwOQbrnxgQ@mail.gmail.com>
 <CABwTF4VzMJaTLrpYtBj4n9r73TFjffzqpPFeUmJPrkY6cmHEAg@mail.gmail.com>
 <3b1683bc-2630-a0d0-6083-8a45aa1b54bf@joeconway.com>
 <cda17e6d-f625-b45e-dfb9-8d18ed09ecc5@joeconway.com>
 <5dc12198-80ff-4e70-b187-11ef33418411@enterprisedb.com>
 <12f6d0f0-0b5d-46e3-afa9-c35bd418d49f@joeconway.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="dFrdQQN6vUrRvRbD"
Content-Disposition: inline
In-Reply-To: <12f6d0f0-0b5d-46e3-afa9-c35bd418d49f@joeconway.com>
Archived-At: <https://www.postgresql.org/message-id/Zpia8GwTB9turihT%40paquier.xyz>
Precedence: bulk


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

On Wed, Jul 17, 2024 at 07:43:13AM -0400, Joe Conway wrote:
> On 7/16/24 18:14, Tomas Vondra wrote:
>> As for the feature, I've never done a fleet-wide analysis, so if this is
>> one of the main use cases, I'm not really sure I can judge if this is a
>> good tool for that. It seems like it might be a convenient way to do
>> that, but does that require we add the module to contrib?
>=20
> I had an offlist chat with Andres about this IIRC and he suggested he
> thought it ought to be just built in to the backend as part of the
> statistics subsystem. Lately though I have been toying with the idea of
> keeping it as an extension and basing it off Michael Paquier's work for
> Pluggable cumulative statistics.

This may live better as a contrib/ module, serving as well as an extra
template for what can be done with the pluggable stats.  Adding that
in core is of course OK for me if that's the consensus.  The APIs for
pluggable stats are really the same as what you would store in core,
minus the system functions you'd want to add in the catalog .dat
files, of course.

I'd like to get it this part done by the end of this commit fest to
have room with pg_stat_statements for this release, but well, we'll
see.  As far as I can see everybody who commented on the thread seems
kind of OK with the idea to fix the stats kinds IDs in time, like
custom RMGRs.  That's just simpler implementation-wise, but I'm also
looking for more opinions.

> Hmm, yeah, I had been planning to include postgres version as part of the
> output, but maybe it would need to be part of the key.

Seems to me that you should do both, then: add PG_VERSION to the
entries, and hash the keys with it for uniqueness.  You could also
have a reset function that performs a removal of the stats for
anything else than the current PG_VERSION, for example.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmaYmvAACgkQnvQgOdby
QH1Jig//bjoqvGEHQwPpoiN+ciEdBBCb992camAxa4xeVFO2HyBcMwDUUP0ROwmD
OwN6UETd9HjPhoqaqIGzwMQJeI4Eeotlw4K/333WRuXiODWTsTYMeSzo6qx6R0+1
KqtVcAw31T+VGebzfFRUsnHwu9/trPYKJtLWdRf8bnkWz6pQPb68KdAtJ/YtMASl
K7Je5u4UgTyKDsjxqcVrOHQ5EY1UHS6QW+sDvq1Ujtyqns4WcldNrWolJpV/2DGz
ip1/EdkU1WYDvM+LeaXK0vLCMJ4UiejcX4BrygieDAMGmrA6rWjs+PWoVZoECTpL
qC/gmiT9Y6kny7eXYnkmPtp8cdpVc7+qV/EO0Y5nSamPUkIwZBpmpfFEM0v0RQ9Q
5M0PDzXhU9vH1P3+w7XpgcTIHGFETwUXIFU9q/XZI/4LDximTmtbCeUYTIZKKrF7
i2C7ZII9Af6c67tBbvNb7KpMP3U3T9rpfVnPqUSeuYKps2amBIJ45gi9R0hNIAuz
t/Vnj5lNJdYj3GSh/vOwl7ZoFbpnTKAsc2D9AgmCYt77dCKL0Te9dQfuS/MpHMVa
PL/VXrB5l0I0gcjbdgHPPOEmylZUk8mhOOBlEfQiLpRueSU56BteX2BAM/cgxuZR
9labad7sYACsm6wEZxH0ob7PqlqOi7dZ1EoEsl8tXeTA4etvlv0=
=H8AI
-----END PGP SIGNATURE-----

--dFrdQQN6vUrRvRbD--