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
