Re: Mark all GUC variable as PGDLLIMPORT
| От | Craig Ringer |
|---|---|
| Тема | Re: Mark all GUC variable as PGDLLIMPORT |
| Дата | |
| Msg-id | CAGRY4nxdhf9bOam6QTxrXPLzPPHFJoTxJ6F=NbcOo5Bc2dAi2w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Mark all GUC variable as PGDLLIMPORT (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On Wed, 25 Aug 2021 at 03:13, Robert Haas <robertmhaas@gmail.com> wrote:
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.
В списке pgsql-hackers по дате отправления: