MIME-Version: 1.0
References: <CAFj8pRDAemLyUiu-Cz4P_4i4H86Nf701JSNoKi1Pm1CTyBQuEQ@mail.gmail.com>
 <CAFj8pRBB-QCBZVen-90imEma1aHf2SR2z7=smWksuOhfw-VdrQ@mail.gmail.com>
 <CAFj8pRDDD48iKeAfP3ywomewP-M0ADbJs5gWzM7z1f004jhDVg@mail.gmail.com>
 <CAFj8pRA0p4odDr+cdi0uJAFyM8Er=D_ZBRth89vZyWtyUiOhRw@mail.gmail.com>
 <20230811155526.ed7v77u7bzkmtfju@erthalion.local> <CAFj8pRD+G+thdanhSTyjqXSVexgo-q5VcBJwA9yaufLAUkuS2A@mail.gmail.com>
 <CAFj8pRBcMGDsuGHVgpMU6XTTAFSFVqGf+q3B+t0oFz0GAXr7og@mail.gmail.com>
 <CAFj8pRDbA5pZ52u69h6FFwF8ko4W4cPEMwm_jKKva2Vc4GGfLA@mail.gmail.com>
 <CAFj8pRBo65zvyOGytJXfxiuxmb1-RUtJh4X0jyN+9Pn9Z8UzzA@mail.gmail.com>
 <CAFj8pRBwwXXtECybYr1xYSwx7i105Y-Ai-t3XS+JPHbhui=Yxw@mail.gmail.com> <ZV2djT403EB2haj3@jrouhaud>
In-Reply-To: <ZV2djT403EB2haj3@jrouhaud>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Sun, 26 Nov 2023 19:19:19 +0100
Message-ID: <CAFj8pRBP1G+vywjBy_qqwgfdFNvj3rF+zE5TAo4gVBtXHcs3dg@mail.gmail.com>
Subject: Re: Schema variables - new implementation for Postgres 15
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, 
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>, 
	Sergey Shinderuk <s.shinderuk@postgrespro.ru>, Tomas Vondra <tomas.vondra@enterprisedb.com>, 
	dean.a.rasheed@gmail.com, er@xs4all.nl, joel@compiler.org, 
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000a0ccda060b123b33"
Archived-At: <https://www.postgresql.org/message-id/CAFj8pRBP1G%2BvywjBy_qqwgfdFNvj3rF%2BzE5TAo4gVBtXHcs3dg%40mail.gmail.com>
Precedence: bulk

--000000000000a0ccda060b123b33
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

st 22. 11. 2023 v 7:20 odes=C3=ADlatel Julien Rouhaud <rjuju123@gmail.com>
napsal:

> Hi,
>
> On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:
> >
> > When I thought about global temporary tables, I got one maybe interesti=
ng
> > idea. The one significant problem of global temporary tables is place f=
or
> > storing info about size or column statistics.
> >
> > I think so these data can be stored simply in session variables. Any
> global
> > temporary table can get assigned one session variable, that can hold
> these
> > data.
>
> I don't know how realistic this would be.  For instance it will require t=
o
> properly link the global temporary table life cycle with the session
> variable
> and I'm afraid it would require to add some hacks to make it work as
> needed.
>
> But this still raises the question of whether this feature could be used
> internally for the need of another feature.  If we think it's likely,
> should we
> try to act right now and reserve the "pg_" prefix for internal use rather
> than
> do that a few years down the line and probably break some user code as it
> was
> done recently for the role names?
>

I don't think it is necessary. Session variables (in this design) are
joined with schemas. If we use some session variables for system purposes,
we can use some dedicated schema. But when I think about it in detail,
probably my own dedicated storage (hash table in session memory) can be
much better than session variables. What can be shared (maybe) is probably
sinval message processing.

--000000000000a0ccda060b123b33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi<br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">st 22. 11. 2023 v=C2=A07:20 odes=C3=ADlatel J=
ulien Rouhaud &lt;<a href=3D"mailto:rjuju123@gmail.com">rjuju123@gmail.com<=
/a>&gt; napsal:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Hi,<br>
<br>
On Tue, Oct 17, 2023 at 08:52:13AM +0200, Pavel Stehule wrote:<br>
&gt;<br>
&gt; When I thought about global temporary tables, I got one maybe interest=
ing<br>
&gt; idea. The one significant problem of global temporary tables is place =
for<br>
&gt; storing info about size or column statistics.<br>
&gt;<br>
&gt; I think so these data can be stored simply in session variables. Any g=
lobal<br>
&gt; temporary table can get assigned one session variable, that can hold t=
hese<br>
&gt; data.<br>
<br>
I don&#39;t know how realistic this would be.=C2=A0 For instance it will re=
quire to<br>
properly link the global temporary table life cycle with the session variab=
le<br>
and I&#39;m afraid it would require to add some hacks to make it work as ne=
eded.<br>
<br>
But this still raises the question of whether this feature could be used<br=
>
internally for the need of another feature.=C2=A0 If we think it&#39;s like=
ly, should we<br>
try to act right now and reserve the &quot;pg_&quot; prefix for internal us=
e rather than<br>
do that a few years down the line and probably break some user code as it w=
as<br>
done recently for the role names?<br></blockquote><div><br></div><div>I don=
&#39;t think it is necessary. Session variables (in this design) are joined=
 with schemas. If we use some session variables for system purposes, we can=
 use some dedicated schema. But when I think about it in detail, probably m=
y own dedicated storage (hash table in session memory) can be much better t=
han session variables. What can be shared (maybe) is probably sinval messag=
e processing.<br></div></div></div>

--000000000000a0ccda060b123b33--