Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 22 Jan 2026 11:28:06 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <aXGLNhFVERJz-kl0@paquier.xyz>
References: <CAA5RZ0vgN8nf7yPrk_uNt-ABFtRnRuz7-9CM=qSzUSwj=EEUKw@mail.gmail.com>
 <aWjbBd5z+LJNWX1l@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0t6j0VYuUpxZ8JLq-ERoUriZ0rK=+8PCUtjRirmSmCx7A@mail.gmail.com>
 <aWojE18aF9qj0EPI@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s9j3x5UPpgaQdDyGA=MNjVEkT73SL7LMoVEKUwiZrVqA@mail.gmail.com>
 <aW4gwqVybB4INCvu@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s6FkEHFdgKf8J6vueZGwsH+08LvV0YPBXa4Dw_8QgtTw@mail.gmail.com>
 <aXCroXBLiUpxk0Ap@ip-10-97-1-34.eu-west-3.compute.internal>
 <aXFpAisDKy6g_cKx@paquier.xyz>
 <CAA5RZ0sQxAu6bU8wTgvs+aTSvhBcziH9jCJ27aS1hzKsm2kmTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="v3iVp1sy9Le3/nxx"
Content-Disposition: inline
In-Reply-To: <CAA5RZ0sQxAu6bU8wTgvs+aTSvhBcziH9jCJ27aS1hzKsm2kmTQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aXGLNhFVERJz-kl0%40paquier.xyz>
Precedence: bulk


--v3iVp1sy9Le3/nxx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 21, 2026 at 07:41:30PM -0600, Sami Imseih wrote:
> Another one would be n_mod_since_analyze, That should
> only be updated after commit (or not after rollback). Otherwise,
> it may throw autovanalyze threshold calculations way off. Same
> for n_dead_tup and autovacuum.

Point taken.  It sounds like it is going to be super important to
document in the patch these kind of current expectations, so as one
does not flip the flush mode one way or another incorrectly, or
assigns an incorrect flush mode when adding a new stats kind.  It's
probably worth documenting that the end-of-transaction flush should be
the default norm, while the out-of-transaction case should be an
exception one needs to be careful of.

> Sure, Bertrand mentioned early in the thread that the anytime flushes
> could be made configurable. Perhaps that is a good idea where we can
> default with something large like 10s intervals for anytime flushes, but allow
> the user to configure a more frequent flushes ( although I would think
> that 1 sec is the minimum we should allow ).

Sure, I am just mentioning that we should not be that aggressive for
everybody.  If this can be made configurable on a call-basis, even if
it means a new GUC, that may be better in the long run.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmlxizYACgkQnvQgOdby
QH1KlQ/9Fn+2SdKbaexVgprmTOA5q+06b/EtKz4xZ4h1/N9j0x+VQap10emqLqRR
o5Itr0H8MdJrWlfRXkP3gjUReigVZqZaAndJvFELO50V6gskiwsX+k+3ONZTo0d/
Nhl4BOkmJjSk7Q6jZgCgnAWofJ9aeielSEapu7cVhQXtCqG5EywRdMeX9JdHrIq9
cTZoyVN5vzYWJ3TEjbz5qA0/nOuVoU2edeyk/fqng1AkVkT0jzsJBCwsGbpBCP24
nNlXPURudeYjlWj6EYbWZ/ysII/XDIeopSA66Lm1twjcfeQyo33YqvEjczVDsSlz
aAbuNnVjW4ncygWBYTq4kLTSGttQMTDWKsXn7CWNlbKA+Tlw6X7HgshetGlXcsMZ
oDJgpgr7uJwGN0sXM/A6vKxwjLInI+kle6S83dphe5jdh1FbBu6KLwHaQ/jdj4AC
IwP/lY8UrwgqYLHgbt6UdWVpYgO3ZA2jgoPc9p1uRyeb34nGQIrfNKuR0EDerPEZ
cjPtfYgKXf8NhE58UjkWZ882lUi6ZgpkD/orOWHtoPXmuB3u4QvEB54F1c54HUE4
WQs8wXS3rMOuNe8nc38FY/ph+XtAXFOZzHPteay3GjI+xQHXMJSMpLSBdn5DM5vb
LOCHP0+yxqsx5KshuXABQ+VC96Zoon5v5+Jt3eQNwt3o1CdbrPM=
=uIiP
-----END PGP SIGNATURE-----

--v3iVp1sy9Le3/nxx--