On Wed, 25 Aug 2021 at 03:13, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack <c...@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.
