public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bertrand Drouvot <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: [email protected]
Cc: Zsolt Parragi <[email protected]>
Subject: Re: Flush some statistics within running transactions
Date: Thu, 22 Jan 2026 08:02:01 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAA5RZ0t6j0VYuUpxZ8JLq-ERoUriZ0rK=+8PCUtjRirmSmCx7A@mail.gmail.com>
<[email protected]>
<CAA5RZ0s9j3x5UPpgaQdDyGA=MNjVEkT73SL7LMoVEKUwiZrVqA@mail.gmail.com>
<[email protected]>
<CAA5RZ0s6FkEHFdgKf8J6vueZGwsH+08LvV0YPBXa4Dw_8QgtTw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAA5RZ0sQxAu6bU8wTgvs+aTSvhBcziH9jCJ27aS1hzKsm2kmTQ@mail.gmail.com>
<[email protected]>
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
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Flush some statistics within running transactions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox