Re: pgstat: add pgstat_prep_pending() for entry ref pending setup

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

In response to

Responses

Browse pgsql-hackers by date

  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