Re: global temporary table (GTT) - are there some ideas how to implement it?
| От | Pavel Stehule |
|---|---|
| Тема | Re: global temporary table (GTT) - are there some ideas how to implement it? |
| Дата | |
| Msg-id | CAFj8pRD-SERziXaOj_f92CxTr5gaURJDaFr=_mh4HTy7W6F5tw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: global temporary table (GTT) - are there some ideas how to implement it? (Konstantin Knizhnik <knizhnik@garret.ru>) |
| Список | pgsql-hackers |
On 12/01/2026 8:57 AM, Pavel Stehule wrote:Hi
I do not completely understand how partitioning of system tables can
solve this problem.
Do you propose that each backend has its own (private) partition?
It seems to be impossible and can cause even worse catalog bloating
(instead of one temp table we will have to create temp partitions for
multiple system tables).yes - but what is important - each backend has its own global temp partitions. Then almost all metadata will be static and only statistic related will be temporary.The backend related partitions have to be of global temp table, not local temp table (only then it makes sense).The main target is removing bloat from the system catalog, and it is impossible without storing system data to GTT.So do I correctly understand that at least pg_class and pg_statistics will have two partitions: "global" and "local" and last one will act as GTT: it has shared metadata but private data. It can work for pg_statistics, because it is actually only needed for the particular backend.
But it will not work for pg_class, because all backends should observe information about this table, but each of them should see it's own relpages/reltuples. So we need some kind of CoW here. Not sure that partitioning can solve this problem...
Also even if we manage to somehow solve this problem and provide private version of pg_statistics/pg_class, it is not clear who and when will fill this data.
It will also solve other problems with temporary tables, i.e. connection pooling.
В списке pgsql-hackers по дате отправления: