Hi út 6. 9. 2022 v 0:28 odesílatel Tom Lane <t...@sss.pgh.pa.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 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
