Re: Schema variables - new implementation for Postgres 15 (typo)

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Schema variables - new implementation for Postgres 15 (typo)
Date: 2022-12-23 07:38:43
Message-ID: CAFj8pRAtghLtrOP1JLE+LnyJEnXdtmPL_oXGY_tuBqw7e2qXXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

čt 22. 12. 2022 v 22:23 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > On Thu, Dec 22, 2022 at 08:45:57PM +0100, Pavel Stehule wrote:
> > > From the first look it seems some major topics the discussion is
> evolving
> > > are about:
> > >
> > > * Validity of the use case. Seems to be quite convincingly addressed in
> > > [1] and
> > > [2].
> > >
> > > * Complicated logic around invalidation, concurrent create/drop etc. (I
> > > guess
> > > the issue above is falling into the same category).
> > >
> > > * Concerns that session variables could repeat some problems of
> temporary
> > > tables.
> > >
>

I am sending an updated patch, fixing the mentioned issue. Big thanks for
testing, and checking.

> >
> > Why do you think so? The variable has no mvcc support - it is just stored
> > value with local visibility without mvcc support. There can be little bit
> > similar issues like with global temporary tables.
>
> Yeah, sorry for not being precise, I mean global temporary tables. This
> is not my analysis, I've simply picked up it was mentioned a couple of
> times here. The points above are not meant to serve as an objection
> against the patch, but rather to figure out if there are any gaps left
> to address and come up with some sort of plan with "committed" as a
> final destination.
>

There are some similarities, but there are a lot of differences too.
Handling of metadata is partially similar, but session variable is almost
the value cached in session memory. It has no statistics, it is not stored
in a file. Because there is different storage, I don't think there is some
intersection on implementation level.

Regards

Pavel

Attachment Content-Type Size
v20221223-1-0010-documentation.patch text/x-patch 43.7 KB
v20221223-1-0009-this-patch-changes-error-message-column-doesn-t-exis.patch text/x-patch 26.0 KB
v20221223-1-0008-regress-tests-for-session-variables.patch text/x-patch 60.4 KB
v20221223-1-0006-enhancing-psql-for-session-variables.patch text/x-patch 14.1 KB
v20221223-1-0007-possibility-to-dump-session-variables-by-pg_dump.patch text/x-patch 19.5 KB
v20221223-1-0005-DISCARD-VARIABLES-command.patch text/x-patch 3.2 KB
v20221223-1-0004-support-of-LET-command-in-PLpgSQL.patch text/x-patch 11.9 KB
v20221223-1-0003-LET-command.patch text/x-patch 44.9 KB
v20221223-1-0002-session-variables.patch text/x-patch 111.5 KB
v20221223-1-0001-catalog-support-for-session-variables.patch text/x-patch 89.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2022-12-23 07:42:09 RE: Force streaming every change in logical decoding
Previous Message John Naylor 2022-12-23 07:33:18 Re: [PoC] Improve dead tuple storage for lazy vacuum