Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwTvC-0002yT-Mp for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jan 2020 16:41:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iwTvB-0002TW-DD for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jan 2020 16:41:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwTvA-0002TP-V2 for pgsql-hackers@lists.postgresql.org; Tue, 28 Jan 2020 16:41:01 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iwTv4-00029x-6B for pgsql-hackers@postgresql.org; Tue, 28 Jan 2020 16:40:59 +0000 Received: by mail-lf1-x132.google.com with SMTP id v201so9577125lfa.11 for ; Tue, 28 Jan 2020 08:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h1zAQKJTd8UkyrfIfeNEj2Im7h7BRH5kBLfmX6Tjf+U=; b=Lcaapif5O+eYn/fDQCo2ijRFljgoMaapOoG81pzPpgE3uTb0sOW+3EXF2I2hSwJ1Fq KrTR0NdWfjAVgEYIItqoum73eQoxzxiSi4SzoqpAtAOYsnAlH9MB/qnnty4WCBCmomD2 GzByXCgEM0b2+hjAFqRL7wSqrtNyEPa4OymbFzfPogWmNnAVirKsLnSbsK2w1V7RBG4s r9JoJi6YStSdtrrprS23cS3LPXbxog8Cz6zU0c38lN1eTaZjmIKLAstfiKE7aHtxURBl xTRMCgJizkl/klqX+dOpunHt7wLkDSefPbApSOFUTYaqzhPQTxJWvXKRss/acRRFahjd e54Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h1zAQKJTd8UkyrfIfeNEj2Im7h7BRH5kBLfmX6Tjf+U=; b=nEnl7hP0PhUiMTDop49MfAves/jWer/MOUhLBVeqfmhxNRi5/sazHAXABP4+uwPsoF ogeEI2y9ALmMIHxEZO66NPoJdxguGRcXnoKDEfp3x6KnjPSoEjikttMg0KiXmO1xn0FN bV9X3KTxzQpusAgEqYvvTOqrLunEZQU0Fye+2Tmb03p5XYtqpEU7sT7E4hGeejJMpy8d NFwyMfzfgFq7L4SPHWrOEZHrQvtywzTVlSHi+EyIcWDL3nnG95UCXAmDclZQ/3k/DucK Q+4A9/79xHBGZuGpt39w4I5qq28Hs6fP1lWjmSENK9Drkdi3+GwpFV4KJUn2id/99kaX QXWA== X-Gm-Message-State: APjAAAWXBtvin2HzlA0yGDO93JJ8pGsiGd+plSvawfugPHryg4rcRSqJ gPPbu2SYMUibHlCnYpNB1yJasD0CHb5cEenif5U= X-Google-Smtp-Source: APXvYqximpsvmn35ctMVyjRDgP6IbGtHxXXl9G0rDgv8FeLXCt014qW+qmLejQzJoNHXh98BsGeB9TCcPt2fHSvQunA= X-Received: by 2002:a19:5212:: with SMTP id m18mr2930407lfb.7.1580229652643; Tue, 28 Jan 2020 08:40:52 -0800 (PST) MIME-Version: 1.0 References: <24099f4e-742c-e92b-729c-77bac1ca80d4@postgrespro.ru> <80cf30c2-ebd5-a568-9f62-a970e4d91326@postgrespro.ru> <5767433E-1A77-4682-B3FD-4869911021C8@alibaba-inc.com> <6b7570aa-14ea-2f28-c3b5-74dd785bbafe@postgrespro.ru> <20200105200603.wrb4beacwb57hhpk@development> <33969545-BEF7-4518-A741-302CBF7FF269@alibaba-inc.com> <0498c45c-53cb-d9b0-c1e2-7d2d1a618511@postgrespro.ru> <20200109164829.mdl3z5xalmaqxs67@development> <3fef844f-0e73-8fcb-e4b6-595d6317b191@postgrespro.ru> <20200112015109.caab6qdr2ob6d5jv@development> <9262B679-EA73-495E-82A6-508F5625023F@alibaba-inc.com> In-Reply-To: <9262B679-EA73-495E-82A6-508F5625023F@alibaba-inc.com> From: Pavel Stehule Date: Tue, 28 Jan 2020 17:40:14 +0100 Message-ID: Subject: Re: [Proposal] Global temporary tables To: =?UTF-8?B?5pu+5paH5peMKOS5ieS7jik=?= Cc: Robert Haas , Tomas Vondra , Konstantin Knizhnik , PostgreSQL Hackers , =?UTF-8?B?6JSh5p2+6ZyyKOWtkOWYiSk=?= , "Cai, Le" , =?UTF-8?B?6JCn5bCR6IGqKOmTgeW6tSk=?= Content-Type: multipart/alternative; boundary="0000000000001c0275059d35e30b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000001c0275059d35e30b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=BAt 28. 1. 2020 v 17:01 odes=C3=ADlatel =E6=9B=BE=E6=96=87=E6=97=8C(=E4= =B9=89=E4=BB=8E) napsal: > > > 2020=E5=B9=B41=E6=9C=8824=E6=97=A5 =E4=B8=8A=E5=8D=884:47=EF=BC=8CRobert = Haas =E5=86=99=E9=81=93=EF=BC=9A > > On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra > wrote: > > I proposed just ignoring those new indexes because it seems much simpler > than alternative solutions that I can think of, and it's not like those > other solutions don't have other issues. > > > +1. > > I complete the implementation of this feature. > When a session x create an index idx_a on GTT A then > For session x, idx_a is valid when after create index. > For session y, before session x create index done, GTT A has some data, > then index_a is invalid. > For session z, before session x create index done, GTT A has no data, > then index_a is valid. > > > For example, I've looked at the "on demand" building as implemented in > global_private_temp-8.patch, I kinda doubt adding a bunch of index build > calls into various places in index code seems somewht suspicious. > > > +1. I can't imagine that's a safe or sane thing to do. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > Opinion by Pavel > + rel->rd_islocaltemp =3D 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? > Opinion by Konstantin Knizhnik > 1 Fixed comments > 2 Fixed assertion > > > Please help me review. > > > Wenjing > > --0000000000001c0275059d35e30b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=C3=BAt 28. 1. 2020 v=C2=A017:01 odes= =C3=ADlatel =E6=9B=BE=E6=96=87=E6=97=8C(=E4=B9=89=E4=BB=8E) <wenjing.zwj@alibaba-inc.com> nap= sal:


2020=E5=B9=B41=E6=9C=8824=E6=97=A5 =E4=B8=8A=E5=8D=884:47=EF=BC=8CRobert H= aas <robertmh= aas@gmail.com> =E5=86=99=E9=81=93=EF=BC=9A

On Sat= , Jan 11, 2020 at 8:51 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> w= rote:
I proposed just ignoring those new index= es because it seems much simpler
than alternative solutions that I can t= hink of, and it's not like those
other solutions don't have othe= r issues.

+1.
I complete th= e implementation of this feature.
When a session x create an inde= x idx_a on GTT A then
For=C2=A0session x,= idx_a is valid when after create index.
For=C2=A0sessio= n y, before=C2=A0session x=C2=A0create=C2=A0index=C2=A0done, GTT A has som= e data, then index_a is invalid.
<= span>For=C2=A0session z,=C2= =A0before=C2=A0session x=C2=A0create=C2=A0index=C2=A0done,=C2=A0GTT= A has no data, then=C2=A0index_a i= s=C2=A0valid.

=

For example, I've looked at the "on demand" building as imp= lemented in
global_private_temp-8.patch, I kinda doubt adding a bunch of= index build
calls into various places in index code seems somewht suspi= cious.

+1. I can't imagine that's a safe or san= e thing to do.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.comThe Enterprise PostgreSQL Company

O= pinion by Pavel
+ rel->rd_isl= ocaltemp =3D true;=C2=A0 <<<<<<< if this is valid, the= n the name of field "rd_islocaltemp" is not probably best<= /div>
I renamed rd_islocaltemp

I don't see any change?=



Opinion by=C2=A0Konstantin Knizhnik
1=C2=A0Fixed comments<= /span>
2=C2=A0Fixed assertio= n

<= /div>

Please help me review.


Wenjing

--0000000000001c0275059d35e30b--