Re: Flush some statistics within running transactions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Flush some statistics within running transactions
Date
Msg-id aXGLNhFVERJz-kl0@paquier.xyz
Whole thread Raw
In response to Re: Flush some statistics within running transactions  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Flush some statistics within running transactions
List pgsql-hackers
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.

> 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.  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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Add missing JIT inline pass for llvm>=17
Next
From: Tom Lane
Date:
Subject: Re: Remove no-op pull_var_clause flag