Re: Flush some statistics within running transactions

Hi,

On Mon, Feb 02, 2026 at 04:31:48PM +0900, Michael Paquier wrote:
> On Sat, Jan 31, 2026 at 11:16:03AM -0600, Sami Imseih wrote:
> > Also, the anytime flush callback does not need to check if there are
> > any variable-numbered stats to flush. This will not be needed as
> > it is in v4-0004
> >
> > ```
> > + /*
> > + * Check if there are any non-transactional stats to flush. Avoid
> > + * unnecessarily locking the entry if nothing accumulated.
> > + */
> > + if (!(lstats->counts.numscans > 0 ||
> > + lstats->counts.tuples_returned > 0 ||
> > + lstats->counts.tuples_fetched > 0 ||
> > + lstats->counts.blocks_fetched > 0 ||
> > + lstats->counts.blocks_hit > 0))
> > + return true;
> > ```
>
> I think that this kind of check may finish by being expensive.
> Reducing the number of fields to check for a non-flushing state, if
> required, would be preferrable.

Done, in v5 just shared up-thread.

Oh and I forgot to mention that with the new design in v5, then the fix for
the issue discovered by Masao-san is not needed anymore (and so has been removed
from 0001).

Regards,

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