Re: [Proposal] Global temporary tables

Поиск
Список
Период
Сортировка
От wenjing
Тема Re: [Proposal] Global temporary tables
Дата
Msg-id CA+B_3Vn0-v35p7Sz0HyXipQpT=apHtrjqQmETs0Dg1GPLVPG6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Proposal] Global temporary tables  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: [Proposal] Global temporary tables  (wenjing <wjzeng2012@gmail.com>)
Список pgsql-hackers


Dilip Kumar <dilipbalaut@gmail.com> 于2021年5月10日周一 下午6:44写道:
On Thu, Apr 22, 2021 at 1:11 PM wenjing <wjzeng2012@gmail.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
 
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: RFC: Logging plan of the running query