Hi
I wrote simple benchmarks. I checked the possible slowdown of connections to postgres when GTT is used.
/usr/local/pgsql/master/bin/pgbench -c 10 -C -f script4.sql -t 1000
script has one line just with INSERT or SELECT LIMIT 1;
PATCH
insert to global temp table (with connect) -- 349 tps (10 clients 443tps)
select from gtt (with connects) -- 370 tps (10 clients 446tps)
insert to normal table (with connect) - 115 tps (10 clients 417 tps)
select from normal table (with connect) -- 358 (10 clients 445 tps)
MASTER
insert to temp table (with connect) -- 58 tps (10 clients 352 tps) -- after test pg_attribute bloated to 11MB
insert into normal table (with connect) -- 118 tps (10 clients 385)
select from normal table (with connect) -- 346 tps (10 clients 449)
The measurement doesn't show anything interesting - it is not possible to see the impact of usage of GTT on connect time.
It is interesting to see the overhead of local temp tables against global temp tables - the performance is about 6x worse, and there is a significant bloat of the pg_attribute table. And the tested table had only one column. So an idea or concept of global temp tables is very good, and implementation looks well (from performance perspective).
I didn't check the code yet, I just tested behaviour and I think it is very satisfiable for the first stage and first release. The patch is long now, and for the first step is good to stop in implemented features.
Next steps should be supporting DDL for actively used GTT tables. This topic is pretty complex, there are possible more scenarios. I think so GTT behaviour should be the same like behaviour of normal tables (by default) - but I see an advantage of other possibilities, so I don't want to open the discussion about this topic now. Current implementation should not block any possible implementations in future.
Regards
Pavel
