| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Subject: | Re: Flush some statistics within running transactions |
| Date: | 2026-02-02 07:31:48 |
| Message-ID: | aYBS5BghHtloMN6b@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-02 07:35:38 | Re: IO wait events for COPY FROM/TO PROGRAM or file |
| Previous Message | Zhijie Hou (Fujitsu) | 2026-02-02 07:27:14 | RE: Improve pg_sync_replication_slots() to wait for primary to advance |