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
