MIME-Version: 1.0
References: <aZLVDJLTiFlxsWZi@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tPsU_bCATn-Wtf8hMaKmrCwfxtLcY9Pp3NQPpLrH2G_Q@mail.gmail.com>
 <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>
In-Reply-To: <aZwMdVBYobV41duU@ip-10-97-1-34.eu-west-3.compute.internal>
From: Sami Imseih <samimseih@gmail.com>
Date: Mon, 23 Feb 2026 17:47:22 -0600
Message-ID: <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
Subject: Re: Flush some statistics within running transactions
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Fujii Masao <masao.fujii@gmail.com>, 
	pgsql-hackers@lists.postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAA5RZ0vaB%2BfXHt76bi_Koj33JoerdgfMYFxHn-D1N%2BSPSGwL2w%40mail.gmail.com>
Precedence: bulk

> > For variable-length statistics, perhaps we can do things a bit
> > differently than what is currently proposed. 0005 requires
> > a relation anytime stat update to call
> > pgstat_schedule_anytime_update(). This is done this way because
> > it allows long-running queries to update their stats every
> > stats_flush_interval using a timeout.
> >
> > But maybe what we should be doing for variable-numbered stats is
> > to schedule an anytime update whenever a "transaction goes idle".
>
> 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 could
> genereate reads/hits IO visible in pg_stat_io but tuples_returned, tuples_fetched,
> blocks_fetched or blocks_hit would not be updated until the session goes idle.

After having more time to think about this, I believe it can be much simpler.
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 whenever
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.

In my mind, this makes this whole flushing scheduling behavior easy to reason
about, and if we introduce future anytime stats anywhere, we are not required
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.

What do you think?

--
Sami Imseih
Amazon Web Services (AWS)