| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgstat: add pgstat_prep_pending() for entry ref pending setup |
| Date: | 2026-07-16 02:11:49 |
| Message-ID: | alg95YayldVSIAOy@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 15, 2026 at 08:40:21PM -0500, Sami Imseih wrote:
> What I am saying is that in order to perform steps 1-4 with individual
> steps rather than the single pgstat_prep_pending_entry(), the API for
> step 4, to prepare the pending entry, is missing.
>
> In the common fast path case (step 1 succeeds, entry already exists), I have
> a valid entry_ref from pgstat_get_entry_ref(create=false). To attach
> pending data to it without the proposed API, I would have to call
> pgstat_prep_pending_entry(), which internally calls pgstat_get_entry_ref
> (create=true) again. That repeats all the work that was already done in
> step 1, key initialization, setup checks, the GC scan
> (pgstat_need_entry_refs_gc),
> and the local cache lookup, all to get back the same entry I already hold.
>
> pgstat_prep_pending() avoids that: it attaches pending data directly
> to the entry_ref I already have, with none of the redundant overhead.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-07-16 02:41:51 | Re: sequencesync worker race with REFRESH SEQUENCES |
| Previous Message | Sami Imseih | 2026-07-16 01:40:21 | Re: pgstat: add pgstat_prep_pending() for entry ref pending setup |