Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 24 Feb 2026 10:56:16 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Fujii Masao <masao.fujii@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <aZ0FQNIP8-bIA2FI@paquier.xyz>
References: <aZQTCJJm61J/X4nC@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vDh+vbE5SY-+azQBxEhXrywaXGrK_Qn8DKEBwNsrDH_Q@mail.gmail.com>
 <aZVQ3nT9B6ti8whJ@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZaKVOrRO_bHsevn@paquier.xyz>
 <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q@mail.gmail.com>
 <aZiD74ZVehxfgqxM@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0t1DsB5x_reGAv0AcKdKuF5FTowUx54SLnWkD3w5vH4Lg@mail.gmail.com>
 <aZwMdVBYobV41duU@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="L0uppPPSVDe0YyGT"
Content-Disposition: inline
In-Reply-To: <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aZ0FQNIP8-bIA2FI%40paquier.xyz>
Precedence: bulk


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

On Mon, Feb 23, 2026 at 05:47:22PM -0600, Sami Imseih wrote:
>> I think the logic for fixed stats and variable stats should be the same.=
 If
>> not we could observe discrepancies: for example a long running select co=
uld
>> genereate reads/hits IO visible in pg_stat_io but tuples_returned, tuple=
s_fetched,
>> blocks_fetched or blocks_hit would not be updated until the session goes=
 idle.
>=20
> After having more time to think about this, I believe it can be much simp=
ler.
> As soon as we enter an idle-in-transaction (aborted) state, we can simply
> schedule an anytime update. This ensures that a flush is scheduled whenev=
er
> the fixed stats trigger one, which will likely be the most common reason
> (e.g., I/O stats, WAL stats, etc.). To cover the cases where fixed stats
> do not schedule a flush, we can also schedule one as soon as a transaction
> goes idle.
>=20
> In my mind, this makes this whole flushing scheduling behavior easy to re=
ason
> about, and if we introduce future anytime stats anywhere, we are not requ=
ired
> to schedule a flush for each individual field. The flush callback will of=
 course
> still need to decide what to flush anytime or at the transaction boundary.
>=20
> What do you think?

I cannot picture yet fully how a patch among these lines would be
shaped, but having a strategic flush of the stats when we are in an
idle-in-transaction state sounds like an interesting option here.

I think that this leans towards two first pieces of infrastructure for
this patch set:
- The new stats kind option.
- A new pgstats API that is able to classify the flushes depending on
property assigned for each stats kind, and make these happen on a
caller-basis.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmdBUAACgkQnvQgOdby
QH0Ueg/8DTwv4//tT/CFKh5PSgsTsgLBKc6JMVdm1bA+ITYPyjkNQw4AtlzpvfS0
JwqVbmPWH+9GkIhFo65TwyDGop2nMDG67+dXIDGMuvOpjC9HSWWSxNoFZ5x4R4FR
A9t/yidwwToq3xDdDV1Gw3lYybES+Y68rOmRgAZGU2un6BKMPmbL7AC+1u2vbPqu
7+3aaDbY4BNskscpZJA7WpIFuDqBGd+4rlSX98x3U0WdjEIr28WU9AAb319xrDyH
+S7X18T/Sq5Qp1UAHP+rDjExULTYKi5BTlpZw1JJq6kn95cGdh8THwqzg/Aaiekn
3wTiibGhhP9HydCaIhYrOlwQdUm3dD92Fls6KEzv3W45muUiglyh0nL/dLhriy0W
h8k15+OsJVWAFsCKzETfWY52TNT1sFCExiQQJlR4GtE+EczWqAgV6mUBexTauLoo
YEc9xbc6X3Wmr+yOON8Qdhinb/bIXDThTsBikCKwcIUjHBTafOR0oha1xUsPB5L8
JnHxtAn+7HJ3vg3K/VnwGYWrU1DmLcjCdTPqqiqGvhZClJzVOWVQk7pI9R1Fvwls
LVNN2t1JXI/28bb2OtTKCeBKXtjygRoMg+HMnS6/XVnTCWIncHovv5Aw+91TKf65
CCO5748NRxxUS1OSwJGjJvJFhhydWBGoVLdE5oo5Eu0cGIWcMns=
=RyFO
-----END PGP SIGNATURE-----

--L0uppPPSVDe0YyGT--