Date: Thu, 22 Jan 2026 08:02:01 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, pgsql-hackers@lists.postgresql.org,
	Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <aXHZeZZMlWls4IBM@ip-10-97-1-34.eu-west-3.compute.internal>
References: <aWjbBd5z+LJNWX1l@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0t6j0VYuUpxZ8JLq-ERoUriZ0rK=+8PCUtjRirmSmCx7A@mail.gmail.com>
 <aWojE18aF9qj0EPI@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s9j3x5UPpgaQdDyGA=MNjVEkT73SL7LMoVEKUwiZrVqA@mail.gmail.com>
 <aW4gwqVybB4INCvu@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s6FkEHFdgKf8J6vueZGwsH+08LvV0YPBXa4Dw_8QgtTw@mail.gmail.com>
 <aXCroXBLiUpxk0Ap@ip-10-97-1-34.eu-west-3.compute.internal>
 <aXFpAisDKy6g_cKx@paquier.xyz>
 <CAA5RZ0sQxAu6bU8wTgvs+aTSvhBcziH9jCJ27aS1hzKsm2kmTQ@mail.gmail.com>
 <aXGLNhFVERJz-kl0@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aXGLNhFVERJz-kl0@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/aXHZeZZMlWls4IBM%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

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