Re: Mark all GUC variable as PGDLLIMPORT

On Wed, 25 Aug 2021 at 03:13, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack <chap(at)anastigmatix(dot)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.