Re: [Proposal] Global temporary tables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [Proposal] Global temporary tables
Date
Msg-id CAFj8pRBtq25tF9O1ioKfAUdvUFzgYQL1Zj9ixdyeXJ7vo7pT=A@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Global temporary tables  (曾文旌 <wenjing.zwj@alibaba-inc.com>)
Responses Re: [Proposal] Global temporary tables  (曾文旌 <wenjing.zwj@alibaba-inc.com>)
Re: [Proposal] Global temporary tables  (曾文旌 <wenjing.zwj@alibaba-inc.com>)
List pgsql-hackers


po 23. 11. 2020 v 10:27 odesílatel 曾文旌 <wenjing.zwj@alibaba-inc.com> napsal:


2020年11月21日 02:28,Pavel Stehule <pavel.stehule@gmail.com> 写道:

Hi

pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 <wenjing.zwj@alibaba-inc.com> napsal:
I have written the README for the GTT, which contains the GTT requirements and design.
I found that compared to my first email a year ago, many GTT Limitations are now gone.
Now, I'm adding comments to some of the necessary functions.

There are problems with patching. Please, can you rebase your patch?
Sure.
I'm still working on sort code and comments.
If you have any suggestions, please let me know.

It is broken again

There is bad white space

+   /*
+    * For global temp table only
+    * use ShareUpdateExclusiveLock for ensure safety
+    */
+   {
+       {
+           "on_commit_delete_rows",
+           "global temp table on commit options",
+           RELOPT_KIND_HEAP | RELOPT_KIND_PARTITIONED,
+           ShareUpdateExclusiveLock
+       },
+       true
+   },  <=================
    /* list terminator */
    {{NULL}}

+7 OTHERS
+Parallel query
+Planner does not produce parallel query plans for SQL related to GTT. Because <=================
+GTT private data cannot be accessed across processes.
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile


+/*
+ * Update global temp table relstats(relpage/reltuple/relallvisible) <========================
+ * to local hashtable
+ */
+void

+/*
+ * Search global temp table relstats(relpage/reltuple/relallvisible) <==============
+ * from lo

and there are lot of more places ...

I found other issue

postgres=# create global temp table foo(a int);
CREATE TABLE
postgres=# create index on foo(a);
CREATE INDEX

close session and in new session

postgres=# reindex index foo_a_idx ;
WARNING:  relcache reference leak: relation "foo" not closed
REINDEX

Regards

Pavel




Wenjing



Regards

Pavel



Wenjing





> 2020年7月31日 上午4:57,Robert Haas <robertmhaas@gmail.com> 写道:
>
> On Thu, Jul 30, 2020 at 8:09 AM wenjing zeng <wjzeng2012@gmail.com> wrote:
>> Please continue to review the code.
>
> This patch is pretty light on comments. Many of the new functions have
> no header comments, for example. There are comments here and there in
> the body of the new functions that are added, and in places where
> existing code is changed there are comments here and there, but
> overall it's not a whole lot. There's no documentation and no README,
> either. Since this adds a new feature and a bunch of new SQL-callable
> functions that interact with that feature, the feature itself should
> be documented, along with its limitations and the new SQL-callable
> functions that interact with it. I think there should be either a
> lengthy comment in some suitable file, or maybe various comments in
> various files, or else a README file, that clearly sets out the major
> design principles behind the patch, and explaining also what that
> means in terms of features and limitations. Without that, it's really
> hard for anyone to jump into reviewing this code, and it will be hard
> for people who have to maintain it in the future to understand it,
> either. Or for users, for that matter.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [PATCH] LWLock self-deadlock detection
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: POC: postgres_fdw insert batching