| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | michael(at)paquier(dot)xyz |
| Cc: | samimseih(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pgstat: add pgstat_prep_pending() for entry ref pending setup |
| Date: | 2026-07-16 04:04:38 |
| Message-ID: | 20260716.130438.779998840458679843.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Thu, 16 Jul 2026 11:11:49 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> Ah, OK. So your argument is about making even the fast path where an
> entry already exists. Indeed that looks like a waste to not do a
> separation. I initially thought that this was no big deal, but now I
> see your point. Your change makes sense, then.
I agree that this change makes sense.
One concern I have is the name of the new function.
pgstat_prep_pending() sounds a bit incomplete. Would a name such as
pgstat_prep_pending_for_entry_ref() be clearer?
Regarding the new function's comment, perhaps it could be phrased
similarly to that of pgstat_prep_pending_entry(), for example:
> Prepare the given entry to receive pending stats, if not already done.
Finally, pgstat_get_entry_ref() does not return NULL when create is
true, but the new function itself does not enforce that assumption. It
might be worth adding an Assert(entry_ref != NULL), in addition to the
assertion on flush_pending_cb.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2026-07-16 04:22:40 | Re: Improve pg_stat_statements scalability |
| Previous Message | Tom Lane | 2026-07-16 02:58:28 | Re: sequencesync worker race with REFRESH SEQUENCES |