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
