Re: [Proposal] Global temporary tables

From: 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tomas Vondra" <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Konstantin Knizhnik" <k(dot)knizhnik(at)postgrespro(dot)ru>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, 蔡松露(子嘉) <zijia(at)taobao(dot)com>, Cai, Le <le(dot)cai(at)alibaba-inc(dot)com>, 萧少聪(铁庵) <shaocong(dot)xsc(at)alibaba-inc(dot)com>
Subject: Re: [Proposal] Global temporary tables
Date: 2020-02-03 13:03:11
Message-ID: CF6C7BCC-0EE7-451A-8537-9109826A9A8E@alibaba-inc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 2020年2月2日 上午2:00,Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 写道:
>
>
>
> so 1. 2. 2020 v 14:39 odesílatel 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com <mailto:wenjing(dot)zwj(at)alibaba-inc(dot)com>> napsal:
>
>
>> 2020年1月30日 下午10:21,Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> 写道:
>>
>>
>>
>> čt 30. 1. 2020 v 15:17 odesílatel 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com <mailto:wenjing(dot)zwj(at)alibaba-inc(dot)com>> napsal:
>>
>>
>> > 2020年1月29日 下午9:48,Robert Haas <robertmhaas(at)gmail(dot)com <mailto:robertmhaas(at)gmail(dot)com>> 写道:
>> >
>> > On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com <mailto:wenjing(dot)zwj(at)alibaba-inc(dot)com>> wrote:
>> >>> Opinion by Pavel
>> >>> + rel->rd_islocaltemp = true; <<<<<<< if this is valid, then the name of field "rd_islocaltemp" is not probably best
>> >>> I renamed rd_islocaltemp
>> >>
>> >> I don't see any change?
>> >>
>> >> Rename rd_islocaltemp to rd_istemp in global_temporary_table_v8-pg13.patch
>> >
>> > In view of commit 6919b7e3294702adc39effd16634b2715d04f012, I think
>> > that this has approximately a 0% chance of being acceptable. If you're
>> > setting a field in a way that is inconsistent with the current use of
>> > the field, you're probably doing it wrong, because the field has an
>> > existing purpose to which new code must conform. And if you're not
>> > doing that, then you don't need to rename it.
>> Thank you for pointing it out.
>> I've rolled back the rename.
>> But I still need rd_localtemp to be true, The reason is that
>> 1 GTT The GTT needs to support DML in read-only transactions ,like local temp table.
>> 2 GTT does not need to hold the lock before modifying the index buffer ,also like local temp table.
>>
>> Please give me feedback.
>>
>> maybe some like
>>
>> rel->rd_globaltemp = true;
>>
>> and somewhere else
>>
>> if (rel->rd_localtemp || rel->rd_globaltemp)
>> {
>> ...
>> }
> I tried to optimize code in global_temporary_table_v10-pg13.patch
>
>
> Please give me feedback.
>
> I tested this patch and I have not any objections - from my user perspective it is work as I expect
>
> +#define RELATION_IS_TEMP(relation) \
> + ((relation)->rd_islocaltemp || \
> + (relation)->rd_rel->relpersistence == RELPERSISTENCE_GLOBAL_TEMP)
>
> It looks little bit unbalanced
>
> maybe is better to inject rd_isglobaltemp to relation structure
>
> and then
>
> it should to like
>
> +#define RELATION_IS_TEMP(relation) \
> + ((relation)->rd_islocaltemp || \
> + (relation)->rd_isglobaltemp))
>
> But I have not idea if it helps in complex
In my opinion
For local temp table we need (relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP
and because one local temp table belongs to only one session, need to mark one sessions rd_islocaltemp = true ,and other to rd_islocaltemp = false.

But For GTT, just need (relation)->rd_rel->relpersistence == RELPERSISTENCE_GLOBAL_GLOBAL_TEMP
One GTT can be used for every session, so no need rd_isglobaltemp anymore. This seems duplicated and redundant.

>
>
>
>
>
>
>
> Wenjing
>
>
>
>>
>>
>>
>> Wenjing
>>
>>
>>
>>
>> >
>> > --
>> > Robert Haas
>> > EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>
>> > The Enterprise PostgreSQL Company
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-02-03 13:19:11 Re: Brokenness in dump/restore for GENERATED expressions
Previous Message Daniel Gustafsson 2020-02-03 12:55:19 Re: BUG #16171: Potential malformed JSON in explain output