Re: Modernizing our GUC infrastructure

út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

> 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 can be persistent - so the usage of session variables
> can be checked by static analyze like plpgsql_check
>

more precious - metadata of session variables are persistent

>
> 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.
>
> Regards
>
> Pavel
>
>
>