Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 4 Jun 2026 13:50:59 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: samimseih@gmail.com, lukas@fittl.com, pgsql-hackers@postgresql.org
Subject: Re: Improve pg_stat_statements scalability
Message-ID: <aiEEM-61KuVBSvxY@paquier.xyz>
References: 
 <CAA5RZ0uoxiQ2_=xHGRnyc4WdM9aR0fzdMhBubnw97po==--yGQ@mail.gmail.com>
 <20260601.135858.1116584574478485492.horikyota.ntt@gmail.com>
 <ah54kGcap-VuWd7y@paquier.xyz>
 <20260603.171039.1005148564287106445.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zRv4oGBBU7vmVioT"
Content-Disposition: inline
In-Reply-To: <20260603.171039.1005148564287106445.horikyota.ntt@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aiEEM-61KuVBSvxY%40paquier.xyz>
Precedence: bulk


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

On Wed, Jun 03, 2026 at 05:10:39PM +0900, Kyotaro Horiguchi wrote:
> One alternative would be to introduce a separate callback for anytime
> flushes. However, since transaction-boundary flushes ultimately need
> to flush everything anyway, it seems to me that passing a context flag
> would be sufficient.

Nah.  I am not really in favor of an extra callback.  I feel that this
could lead to more mistakes when implementing new stats kinds, so
doing your approach of using a value based on the context of the flush
works for me.

> I tend to agree with the single-entry-point approach.
>=20
> The basic operation is common; the anytime case differs only in the
> context in which the flush is requested. The flush-timing logic in
> pgstat_report_stat() may become slightly more complicated with anytime
> flushes, but after that point I think the existing path should
> continue to work with only minor adjustments, by carrying an explicit
> context value down to the callbacks.

Yeah, same feeling here.  That would be the way I'd use to approach
this design, and to aim for one single entry point for all the stats
reports and the flushes, for all the contexts.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmohBDMACgkQnvQgOdby
QH19+RAAhr9FI3ts54jtfvg+HV266il84e0Oa/9snI+L+rnF4RTLvRGRFV1E0DhJ
ErCsX083i2swRAYgNdOHkz4eR2kE5vCW0zGiwl7tAfv4kBSwnIS73CUFUbgLfnBz
3puaVyYjx2I5yx4clzPUUQrVL6zBeGgi9jaoIsa1UYY+3X9HzYXP+hlFRfENX0CJ
HX3MfloPM/c34k/jHG66uAGHo+WRYJKIzwgONeJMaNYy16yKcu6a/1XVAclJwK2D
UxdqOC61acfxJ7RjPKrnX8lX9HE10HzdI3asotTz1t+Mf9zQesUxVJvILfC8p7Y6
LRdNs5YQDg7HPhJEqD8aYo0uBTU7QJ9jc5aYTgEQRCR6LQXanhkvOMsVEmLJ6zgT
QFYeQpywViMxDI39H7vHz/EN+2mJ07vy5kNm71TUO0WvIdV/sug05A5Y5YTvFW66
6uj9inDhx1tK74K2DKZgkDbe9RymIB3+Iv2tP7m862CdavWKEqJwyIv7a0leb3v+
XwabP4ATW1T/pPb4a67zkiLOb0D5NIfFBpdfeFQw8ofUfOighyYWH2kY2CzpoUel
BVRqzLI7zxBmdkTyh2ar91PUssC3q2xSFaGheAUbXDgKTkk/yvIdSfiA3GxGMEUK
kOARrMFVuC49MolAI5fkjGBa4Hn22IPc89y3mu4nfzFO/7f5cCk=
=Bzzk
-----END PGP SIGNATURE-----

--zRv4oGBBU7vmVioT--