Re: [Proposal] Global temporary tables

Dilip Kumar <dilipbalaut(at)gmail(dot)com> 于2021年5月10日周一 下午6:44写道：

> On Thu, Apr 22, 2021 at 1:11 PM wenjing <wjzeng2012(at)gmail(dot)com> wrote:
> >
>
> I have briefly looked into the design comments added by the patch. I
> have a few questions.

> +Feature description
> +--------------------------------
> +
> +Previously, temporary tables are defined once and automatically
> +created (starting with empty contents) in every session before using them.
>
>
> I don’t think this statement is correct, I mean if we define a temp
> table in one session then it doesn’t automatically create in all the
> sessions.
>
The point is the schema definition of GTT which is shared between sessions.
When a session creates a GTT, once the transaction for the Create Table is
committed, other sessions can see the GTT and can use it.
so I modified the description as follows:
automatically exist in every session that needs them.

What do you think?

>
>
> +
> +Like local temporary table, Global Temporary Table supports ON COMMIT
> PRESERVE ROWS
> +or ON COMMIT DELETE ROWS clause, so that data in the temporary table can
> be
> +cleaned up or reserved automatically when a session exits or a
> transaction COMMITs.
>
> /reserved/preserved
>
> OK, I fixed it.

>
> I was trying to look into the “Main design idea” section.
>
> +1) CATALOG
> +GTTs store session-specific data. The storage information of GTTs'data,
> their
> +transaction information, and their statistics are not stored in the
> catalog.
>
> I did not understand what do you mean by “transaction information” is
> not stored in the catalog? Mean what transaction information are
> stored in catalog in the normal table which is not stored for GTT?
>
"Transaction Information" refers to the GTT's relfrozenXID,
The relfrozenxid of a normal table is stored in pg_class, but GTT is not.

Each row of the data (the tuple header) contains transaction information
(such as xmin xmax).
At the same time, for regular table we record the oldest XID (as
relfrozenXID) in each piece of data into the pg_class, which is used to
clean up the data and clog and reuse transactional resources.
My design is:
Each session in GTT has a local copy of data (session level relfrozenXID),
which is stored in memory (local hashtable). and vacuum will refer to this
information.

> +Changes to the GTT's metadata affect all sessions.
> +The operations making those changes include truncate GTT, Vacuum/Cluster
> GTT,
> +and Lock GTT.
>
> How does Truncate or Vacuum affect all the sessions, I mean truncate
> should only truncate the data of the current session and the same is
> true for the vacuum no?

Your understanding is correct.
Truncate GTT, VACUUM/CLUuster GTT, and Lock GTT affect current session and
without causing exclusive locking.
"Changes to the GTT's metadata affect All Sessions. "is not used to
describe the lock behavior. I deleted it.

> I will try to do a more detailed review.
>
Thank you very much for your careful review. We are closer to success.

>
> --
> Regards,
> Dilip Kumar
> EnterpriseDB: http://www.enterprisedb.com
>
>
>

I updated the code and passed the regression tests.

Regards,
wjzeng