On Mon, Aug 03, 2026 at 04:51:56PM -0500, Sami Imseih wrote: > Where this may become questionable is because there is slightly more > locking overhead if we go with the registry approach. The registry path goes > through more locking during backend startup (attaching to the > registry's own DSA, > looking up the entry, then attaching to the pgstat DSA) compared to the > current code which does a single dsa_attach_in_place at a known address. > With a high connection churn benchmark, using -C > > ``` > pgbench -C -c $clients -T 10 -n -f bench.sql > ``` > > 35-40 microseconds, but this is an extreme case of high connection churn.
I am not troubled by these numbers myself; that's barely noticeable. But I have to admit that some folks around here would likely complain if we change that, so I would live the optimization in place, and just give up on the idea. Sad, but well, I like the concept of a peaceful life if I can. Saying that. Do you think that there could be a path forward where we could optimize the registry locking, benefiting everybody who uses this API? Just trying to think about all the sides of the coin. -- Michael
signature.asc
Description: PGP signature
