Re: [Proposal] Global temporary tables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [Proposal] Global temporary tables
Date
Msg-id CAFj8pRCp+r=WRXryPQ1Lxhq-tfZqomp00FjddUztqWaAOO4Pxg@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Global temporary tables  (曾文旌 <wenjing.zwj@alibaba-inc.com>)
Responses Re: [Proposal] Global temporary tables
List pgsql-hackers
Hi
 
GTT Merge the latest PGMaster and resolves conflicts.



I tested it and it looks fine. I think it is very usable in current form, but still there are some issues:

postgres=# create global temp table foo(a int);
CREATE TABLE
postgres=# insert into foo values(10);
INSERT 0 1
postgres=# alter table foo add column x int;
ALTER TABLE
postgres=# analyze foo;
WARNING:  reloid 16400 not support update attstat after add colunm
WARNING:  reloid 16400 not support update attstat after add colunm
ANALYZE

Please, can you summarize what is done, what limits are there, what can be implemented hard, what can be implemented easily?



I found one open question - how can be implemented table locks - because data is physically separated, then we don't need table locks as protection against race conditions.

Now, table locks are implemented on a global level. So exclusive lock on GTT in one session block insertion on the second session. Is it expected behaviour? It is safe, but maybe it is too strict.

We should define what table lock is meaning on GTT.

Regards

Pavel
 
Pavel


With Regards,
Prabhat Kumar Sahu
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)
Next
From: "Daniel Verite"
Date:
Subject: Re: Multi-byte character case-folding