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
signature.asc
Description: PGP signature
