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 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?
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
signature.asc
Description: PGP signature
