Re: Flush some statistics within running transactions

On Wed, Jan 21, 2026 at 10:34:09AM +0000, Bertrand Drouvot wrote:
> No, 0003 also changes the flush mode for the database KIND. All the fields that
> I mentioned are inherited from relations stats and are flushed only at transaction
> boundaries (so they don't appear in pg_stat_database until the transaction
> finishes). Does that make sense? (if the database kind is not switched to
> flush any time then none would appear while the transaction is in progress, even
> the ones inherited from relations stats).
>
> PFA v3, also taking care of Zsolt's comment (thanks!) done up-thread.

While reading through 0001, I got to question on which properties
and/or assumptions of a stats kind one has to rely on to decide to
what flush_mode should be set. To put is simpler, why don't we just
do a periodic pgstat_report_stat(false) call that would flush all the
stats for all stats kinds based on the new timeout registered,
expanding a bit the flush we currently do when idle in
ProcessInterrupts()? It seems that one point of contention should be
that we should be careful with entries in the shmem hash table that
have been created in a transactional way, but we may already flush
them while we are in a transaction state, no? Are there any fields in
a stats kind that we do may not want to flush? If yes, it sounds to
me that it would be better to document these in the structures to
explain the reason why a flush mode is chosen over the other.

I am also not convinced that we have to be that aggressive with these
extra flushes. The target is long-running analytical queries, that
could take minutes or even hours. Using the same value as
PGSTAT_IDLE_INTERVAL (10s), perhaps renaming the value while on it,
would be a more natural fit. A 1s vs 10s report interval does not
really matter for long analytical queries, where I'd imagine data
being picked up on at least a 30s interval, at the shortest. Of
course, one may want to get a more "live" representation of the data
with more aggressive flushes, but is that really helpful for
long-running queries to have more granularity, stressing more the
shmem state?
--
Michael