Date: Mon, 6 Jan 2020 13:52:34 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: =?utf-8?B?5pu+5paH5peMKOS5ieS7jik=?= <wenjing.zwj@alibaba-inc.com>,
	Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
	Pavel Stehule <pavel.stehule@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	=?utf-8?B?6JSh5p2+6ZyyKOWtkOWYiSk=?= <zijia@taobao.com>,
	"Cai, Le" <le.cai@alibaba-inc.com>,
	=?utf-8?B?6JCn5bCR6IGqKOmTgeW6tSk=?= <shaocong.xsc@alibaba-inc.com>
Subject: Re: [Proposal] Global temporary tables
Message-ID: <20200106125234.p65hkqopbzkyrvio@development>
References: 
 <CA+Tgmob_Fg9PfNjjOReJtAE4B5gc8+UqHh+tztJ_C+iRN4KHSw@mail.gmail.com>
 <24099f4e-742c-e92b-729c-77bac1ca80d4@postgrespro.ru>
 <CAFj8pRBo8YZ=bJESqf2fkxGL8Bq2Fs7=SjxisS7UhXHh6yPSfA@mail.gmail.com>
 <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>
 <20200106110119.zfrg2m5e2q5mvi5v@development>
 <CAEZATCW0omTuLCNnPym4F8GMLBX-WZpAS3FpZyU06mkHPoOi_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAEZATCW0omTuLCNnPym4F8GMLBX-WZpAS3FpZyU06mkHPoOi_g@mail.gmail.com>
Precedence: bulk

On Mon, Jan 06, 2020 at 12:17:43PM +0000, Dean Rasheed wrote:
>On Mon, 6 Jan 2020 at 11:01, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>>
>> On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
>>
>> >2 We feel that gtt needs to maintain statistics, but there is no
>> >agreement on what it will be done.
>> >
>>
>> I certainly agree GTT needs to maintain statistics, otherwise it'll lead
>> to poor query plans.
>
>+1
>
>> AFAIK the current patch stores the info in a hash
>> table in a backend private memory, and I don't see how else to do that
>> (e.g. storing it in a catalog would cause catalog bloat).
>>
>
>It sounds like it needs a pair of system GTTs to hold the table and
>column statistics for other GTTs. One would probably have the same
>columns as pg_statistic, and the other just the relevant columns from
>pg_class. I can see it being useful for the user to be able to see
>these stats, so perhaps they could be UNIONed into the existing stats
>view.
>

Hmmm, yeah. A "temporary catalog" (not sure if it can work exactly the
same as GTT) storing pg_statistics data for GTTs might work, I think. It
would not have the catalog bloat issue, which is good.

I still think we'd need to integrate this with the regular pg_statistic
catalogs somehow, so that people don't have to care about two things. I
mean, extensions like hypopg do use pg_statistic data to propose indexes
etc. and it would be nice if we don't make them more complicated.

Not sure why we'd need a temporary version of pg_class, though?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services