Re: [Proposal] Global temporary tables
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Global temporary tables |
Дата | |
Msg-id | 20200106125234.p65hkqopbzkyrvio@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Global temporary tables (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | 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.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
В списке pgsql-hackers по дате отправления: