Hi,
On Wed, Feb 04, 2026 at 10:26:35AM -0600, Sami Imseih wrote:
> > Will address below in the comments.
>
> Sorry there was one more comment I forgot about.
>
> in v5-0004, instead of `flush_anytime_cb`, can't we
> just pass the anytime flag to the `flush_pending_cb` and
> take care of what needs to be flushed there?
>
> It will be up to the author of the kind if they want to further
> split work in multiple functions, but we could just have a
> single callback that is ANYTIME aware.
Thank you Sami and Zsolt for the reviews!
PFA attached v6, addressing the reviews comments.
Main changes are:
0001:
- Adds a pgstat_schedule_anytime_update() macro to schedule the next anytime flush
- The flush_pending_cb and flush_static_cb callbacks now receive an anytime_only
boolean parameter. Most of the time it's not used (except for assertions), but it's
preparatory work for moving the relations stats to anytime (without introducing
a new callback) in 0005.
0002:
Add some tests for anytime flush on custom stats. It adds a few functions:
we could/may want to avoid some duplicate code and update the version to 1.1
though. For the former, I don't have a strong opinion and for the later I'm not
sure (for example 07ff701dbd53 did not bump the version).
0005:
Get rid of the FLUSH_MIXED mode, the new anytime callback and the
pgstat_report_mixed_anytime variable introduced in v5. Instead v6:
- change RELATION and DATABASE kinds from FLUSH_AT_TXN_BOUNDARY to FLUSH_ANYTIME
- Modify pgstat_relation_flush_cb() to handle anytime_only parameter: when
true, then flush only non-transactional stats and when false, then flush all
the stats
Remark:
I did not add any additional checks in pgstat_report_anytime_stat(), since we
enter it for good reason: at least one the flush has to be triggered. I'm not sure
it's worth to add more check to try to discard one of them. The flush functions
return early if they don't have anything to flush anyway. So the gain would be
to try to avoid one function call at pgstat_flush_interval interval, but we would
need to maitain the variable(s) and avoid possible race conditions with
pgstat_report_stat().
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
