On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack <chap@anastigmatix.net> wrote: > I don't think that's true of the second proposal in [0]. I don't foresee > a noticeable runtime cost unless there is a plausible workload that > involves very frequent updates to GUC settings that are also of interest > to a bunch of extensions. Maybe I'll take a stab at a POC.
I'm not sure I fully understand that proposal, but I find it hard to believe that we would seriously consider replacing every direct GUC reference in the backend with something that goes through an API. Even if didn't hurt performance, I think it would uglify the code a whole lot.
It'd probably have to be something that resolves the GUC storage addresses at compile-time or once at runtime, if it's going to be used by core code. While some code doesn't hit a lot of GUCs, some *really* hammers some common GUCs.
There are various issues with cache lines and pointer chasing that are beyond my low-level fu at work here. Adding a level of pointer indirection can be very expensive in the wrong situations.
So you're probably looking at some kind of mess with token pasting, macros and static inlines. Ew.