Re: Flush some statistics within running transactions

Hi,

On Thu, Jan 22, 2026 at 11:28:06AM +0900, Michael Paquier wrote:
> On Wed, Jan 21, 2026 at 07:41:30PM -0600, Sami Imseih wrote:
> > Another one would be n_mod_since_analyze, That should
> > only be updated after commit (or not after rollback). Otherwise,
> > it may throw autovanalyze threshold calculations way off. Same
> > for n_dead_tup and autovacuum.
> 
> Point taken.  It sounds like it is going to be super important to
> document in the patch these kind of current expectations, so as one
> does not flip the flush mode one way or another incorrectly, or
> assigns an incorrect flush mode when adding a new stats kind.  It's
> probably worth documenting that the end-of-transaction flush should be
> the default norm, while the out-of-transaction case should be an
> exception one needs to be careful of.

Agreed, I'll add more explanations around that.

> > Sure, Bertrand mentioned early in the thread that the anytime flushes
> > could be made configurable. Perhaps that is a good idea where we can
> > default with something large like 10s intervals for anytime flushes, but allow
> > the user to configure a more frequent flushes ( although I would think
> > that 1 sec is the minimum we should allow ).
> 
> Sure, I am just mentioning that we should not be that aggressive for
> everybody.

I'm not opposed to increase the flush frequency but I suppose most of the monitoring
tools are sampling at a 1s frequency. So, if we set the flush frequency to say 10s,
that would result in "spikes" every 10s. That's misleading, because it's not a
spike in activity, it's a delay in reporting.

I think that would make sense if we expect the 1s interval to have a negative
impact, but that's not what I expect and observed.

> If this can be made configurable on a call-basis, even if
> it means a new GUC, that may be better in the long run.

If we think that the 1s interval is a problem, we could go in that direction.
Though it might be better to hardcode a larger value instead of letting the users
set values that could be problematic.

Regards,

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