Re: Modernizing our GUC infrastructure

út 6. 9. 2022 v 7:42 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> > napsal:
> >> 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
>
> Right ... so the question is, is that a feature or a bug?
>
> I think there's a good analogy here to temporary tables. The SQL
> spec says that temp-table schemas are persistent and database-wide,
> but what we actually have is that they are session-local. People
> occasionally propose that we implement the SQL semantics for that,
> but in the last twenty-plus years no one has bothered to write a
> committable patch to support it ... much less remove the existing
> behavior in favor of that, which I'm pretty sure no one would think
> is a good idea.
>
> So, is it actually a good idea to have persistent metadata for
> session variables? I'd say that the issue is at best debatable,
> and at worst proven wrong by a couple of decades of experience.
> In what way are session variables less mutable than temp tables?
>

The access pattern is very different. The session variable is like the temp
table with exactly one row. It reduces a lot of overheads with storage (for
reading, for writing).

For example, the minimum size of an empty temp table is 8KB. You can store
all "like" session values to one temp table, but then there will be brutal
overhead with reading.

>
> Still, this discussion would be better placed on the other thread.
>

sure - faster GUC is great - there are a lot of applications that overuse
GUC, because there are no other solutions now. But I don't think so it is
good solution when somebody need some like global variables in procedural
code. And the design of session variables is more wide.

Regards

Pavel

>
> regards, tom lane
>