Re: Flush some statistics within running transactions

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Bertrand Drouvot <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: [email protected]
Cc: Zsolt Parragi <[email protected]>
Subject: Re: Flush some statistics within running transactions
Date: Tue, 24 Feb 2026 12:01:30 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>
References: <aZQTCJJm61J/[email protected]>
	<CAA5RZ0vDh+vbE5SY-+azQBxEhXrywaXGrK_Qn8DKEBwNsrDH_Q@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q@mail.gmail.com>
	<[email protected]>
	<CAA5RZ0t1DsB5x_reGAv0AcKdKuF5FTowUx54SLnWkD3w5vH4Lg@mail.gmail.com>
	<[email protected]>
	<CAA5RZ0vaB+fXHt76bi_Koj33JoerdgfMYFxHn-D1N+SPSGwL2w@mail.gmail.com>

Hi,

On Mon, Feb 23, 2026 at 05:47:22PM -0600, Sami Imseih wrote:
> > > 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?

My understanding is that (correct me if I'm wrong):

- fixed stats would still be designed the way it is in v11
- variable stats would not need the pgstat_schedule_anytime_update() calls in 
various places. The flush would be done/schedule when the session goes idle.

Then I agree that that looks ok and that:

> 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.)

Though I don't think that adresses Michael's concern: "main worries are
mainly around 1), I guess, with the new SIGALRM handler requirements for all
auxiliary processes" in [1].

Regards,

[1]: https://postgr.es/m/aZznT84Ssh8PywcH%40paquier.xyz

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Flush some statistics within running transactions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox