Re: Modernizing our GUC infrastructure

Hi,

On Tue, Sep 06, 2022 at 06:32:21AM +0200, Pavel Stehule wrote:
> Hi
>
> út 6. 9. 2022 v 0:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>
> > Attached is a patch series that attempts to modernize our GUC
> > infrastructure, in particular removing the performance bottlenecks
> > it has when there are lots of GUC variables. I wrote this because
> > I am starting to question the schema-variables patch [1] --- that's
> > getting to be quite a large patch and I grow less and less sure
> > that it's solving a problem our users want solved. I think what
> > people actually want is better support of the existing mechanism
> > for ad-hoc session variables, namely abusing custom GUCs for that
> > purpose. One of the big reasons we have been resistant to formally
> > supporting that is fear of the poor performance guc.c would have
> > with lots of variables. But we already have quite a lot of them:
> >
> >
> The bad performance is not the main reason for implementing session
> variables (and in almost all cases the performance of GUC is not a problem,
> because it is not a bottleneck, and in some terrible cases, I can save the
> GUC to a variable). There are other differences:
>
> 1. Session variables metadata can be persistent - so the usage of session
> variables can be checked by static analyze like plpgsql_check
>
> 2. Session variables supports not atomic data types - so the work with row
> types or arrays is much more comfortable and faster, because there is no
> conversion string <-> binary
>
> 3. Session variables allows to set access rights
>
> 4. Session variables are nullable and allowed to specify default values.
>
> I don't think so users have ten thousand GUC and the huge count of GUC is
> the main performance problem. The source of the performance problem is
> storing the value only as string.

I think we can also mention those differences with the proposed schema
variables:

- schema variables have normal SQL integration, having to use current_setting()
isn't ideal (on top of only supporting text) and doesn't really play nice
with pg_stat_statements for instance

- schema variables implement stability in a single SQL statement (not in
plpgsql), while current_setting always report the latest set value. This one
may or may not be wanted, and maybe the discrepancy with procedural languages
would be too problematic, but it's still something proposed