út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> 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 > 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 > > >
