Re: [Proposal] Global temporary tables

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-01-06 12:52:34
Message-ID: 20200106125234.p65hkqopbzkyrvio@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 06, 2020 at 12:17:43PM +0000, Dean Rasheed wrote:
>On Mon, 6 Jan 2020 at 11:01, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2020-01-06 13:00:58 Re: Error message inconsistency
Previous Message Fabien COELHO 2020-01-06 12:52:33 Re: Greatest Common Divisor