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

From Bertrand Drouvot
Subject Re: Flush some statistics within running transactions
Date
Msg-id aYDb7g5hXnaP+5BU@ip-10-97-1-34.eu-west-3.compute.internal
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
Re: Flush some statistics within running transactions
List pgsql-hackers
Hi,

On Sat, Jan 31, 2026 at 11:16:03AM -0600, Sami Imseih wrote:
> > This makes things confusing because instead of just relying on
> > dlist_is_empty(&pgStatPending) to check if we need to flush anything,
> > the responsibility now moves to the callback, which now also has to
> > account for all the ANYTIME fields.
> >
> 
> Thinking about this a bit more, it seems the FLUSH_MIXED may
> not be needed. Instead can we just introduce a new global variable
> called pgstat_report_variable_anytime which acts like
> pgstat_report_fixed, except it's set to true whenever we update
> anytime variable-numbered stats
> 
> With this approach, we will not enter pgstat_flush_pending_entries
> inside pgstat_report_anytime_stat unless we have anytime
> variable stats to report.

Thanks for looking at it!

In v5 attached I changed the design so that we don't re-enable the timeout
after each stats flush in ProcessInterrupts(). Instead the timeout is enabled
when we set pgstat_report_fixed to true or in pgstat_prep_pending_entry() when
appropriate. So that we know that when we enter pgstat_report_anytime_stat() that's
for good reasons and we don't need extra checks in it.

> ```
> + /*
> + * 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;
> ```

Yeah, with the new design in place then those are not needed anymore.

> This feels like an easier approach to reason about and we don't
> need to add a third flush mode.

I do think we still need it. Indeed in 0004 that helps distinguish between
anytime flush or mixed flush (with the help of the new pgstat_report_mixed_anytime
global variable) in pgstat_prep_pending_entry().

Thoughts?

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Pasword expiration warning
Next
From: Bertrand Drouvot
Date:
Subject: Re: Flush some statistics within running transactions