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
Re: [Proposal] Global temporary tables |
| 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> 写道：Hipá 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}}
+ * 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
+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
+ * Update global temp table relstats(relpage/reltuple/relallvisible) <========================
+ * to local hashtable
+ */
+void
+/*
+ * Search global temp table relstats(relpage/reltuple/relallvisible) <==============
+ * from lo
+ * 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
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
WARNING: relcache reference leak: relation "foo" not closed
REINDEX
Regards
Pavel
WenjingRegardsPavel
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: