| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Mark all GUC variable as PGDLLIMPORT |
| Date: | 2021-08-24 04:58:37 |
| Message-ID: | CAOBaU_b0vBi1ua6f3_3O2LC3OEdrv-mhAnVXxmP7OVFwkAO3jA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 24, 2021 at 12:36 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> There are few GUC variables, where we need extra fast access - work_mem, encoding settings, and maybe an application name. For others I hadn't needed to access it for over 20 years. But I understand that more complex extensions like timescaledb will use more internal GUC.
Note that even trivial extensions require some other GUC access. For
instance any single extension that wants to aggregate data based on
the query_id has to store an array of query_id in shmem to know what a
parallel worker is working on. On top of wasting memory and CPU, it
also means that computing the maximum number of backends in required.
So you need to recompute MaxBackends, which means access to multiple
GUCs.
Unfortunately the patch to expose the query_id didn't fix that problem
as it only passes the top level query_id to the pararllel workers, not
the current one.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2021-08-24 05:02:42 | Re: Mark all GUC variable as PGDLLIMPORT |
| Previous Message | Pavel Stehule | 2021-08-24 04:35:56 | Re: Mark all GUC variable as PGDLLIMPORT |