Re: [Proposal] Global temporary tables
От | Konstantin Knizhnik |
---|---|
Тема | Re: [Proposal] Global temporary tables |
Дата | |
Msg-id | 136fcaf5-2841-6435-7640-be04c4891143@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [Proposal] Global temporary tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [Proposal] Global temporary tables
|
Список | pgsql-hackers |
On 01.11.2019 18:26, Robert Haas wrote: > On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik > <k.knizhnik@postgrespro.ru> wrote: >> It seems to me that I have found quite elegant solution for per-backend statistic for GTT: I just inserting it in backend'scatalog cache, but not in pg_statistic table itself. >> To do it I have to add InsertSysCache/InsertCatCache functions which insert pinned entry in the correspondent cache. >> I wonder if there are some pitfalls of such approach? > That sounds pretty hackish. You'd have to be very careful, for > example, that if the tables were dropped or re-analyzed, all of the > old entries got removed -- I have checked it: - when table is reanalyzed, then cache entries are replaced. - when table is dropped, then cache entries are removed. > and then it would still fail if any code > tried to access the statistics directly from the table, rather than > via the caches. My assumption is that the statistics ought to be > stored in some backend-private data structure designed for that > purpose, and that the code that needs the data should be taught to > look for it there when the table is a GTT. Yes, if you do "select * from pg_statistic" then you will not see statistic for GTT in this case. But I do not think that it is so critical. I do not believe that anybody is trying to manually interpret values in this table. And optimizer is retrieving statistic through sys-cache mechanism and so is able to build correct plan in this case. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: