Re: [Proposal] Global temporary tables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [Proposal] Global temporary tables
Дата
Msg-id CAFj8pRBJcUGKoOzONsh_140Kk4F_f1y2TtUK=J=z8QsUtwDrFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Proposal] Global temporary tables  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers



And pg_catalog.pg_statistics_gtt() is set returning functions?

yes

I afraid that it is not acceptable solution from performance point of view: pg_statictic table is accessed by keys (<relid>,<attpos>,<inh>)

I don't think so it is problem. The any component, that needs to use fast access can use some special function that check index or check some memory buffers.


If it can not be done using index scan, then it can cause significant performance slow down.

where you need fast access when you use SQL access? Inside postgres optimizer is caches everywhere. And statistics cache should to know so have to check index and some memory buffers.

The proposed view will not be used by optimizer, but it can be used by some higher layers. I think so there is a agreement so GTT metadata should not be stored in system catalogue. If are stored in some syscache or somewhere else is not important in this moment. But can be nice if for user the GTT metadata should not be black hole. I think so is better to change some current tables to views, than use some special function just specialized for GTT (these functions should to exists in both variants). When I think about it - this is important not just for functionality that we expect from GTT. It is important for consistency of Postgres catalog - how much different should be GTT than other types of tables in system catalogue from user's perspective.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting psql to redisplay command after \e
Следующее
От: Oleksii Kliukin
Дата:
Сообщение: pg_upgrade and subscriptions