Re: [Proposal] Global temporary tables

Hi

this patch is broken now. Please, can you check it?

Regards

Pavel

st 25. 11. 2020 v 14:08 odesílatel 曾文旌 <wenjing(dot)zwj(at)alibaba-inc(dot)com> napsal:

>
>
> 2020年11月25日 14:19，Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 写道：
>
>
>
> po 23. 11. 2020 v 10:27 odesílatel 曾文旌 <wenjing(dot)zwj(at)alibaba-inc(dot)com>
> napsal:
>
>>
>>
>> 2020年11月21日 02:28，Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 写道：
>>
>> Hi
>>
>> pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 <wenjing(dot)zwj(at)alibaba-inc(dot)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
>
>
> I fixed all the above issues and rebase code.
> Please review the new version code again.
>
>
> Wenjing
>
>
>
>
> Regards
>
> Pavel
>
>
>
>>
>> Wenjing
>>
>>
>>
>> Regards
>>
>> Pavel
>>
>>
>>>
>>> Wenjing
>>>
>>>
>>>
>>>
>>>
>>> > 2020年7月31日 上午4:57，Robert Haas <robertmhaas(at)gmail(dot)com> 写道：
>>> >
>>> > On Thu, Jul 30, 2020 at 8:09 AM wenjing zeng <wjzeng2012(at)gmail(dot)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
>>>
>>>
>>
>