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

From Michael Paquier
Subject Re: Flush some statistics within running transactions
Date
Msg-id aYBS5BghHtloMN6b@paquier.xyz
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
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Michael Paquier
Date:
Subject: Re: IO wait events for COPY FROM/TO PROGRAM or file