Re: [HACKERS] Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
On Tue, Aug 23, 2016 at 8:50 PM, Greg Stark wrote: > On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev > wrote: >> Frankly I have much more faith in Tom's idea of using virtual part of the >> catalog for all temporary tables, i.e turning all temporary tables into >> "fast" temporary tables. Instead of introducing a new type of temporary >> tables >> that solve catalog bloating problem and forcing users to rewrite applications >> why not just not to create a problem in a first place? > > Would applications really need to be rewritten? Are they really > constructing temporary tables where the definition of the table is > dynamic, not just the content? Mine is. But it wouldn't be a big deal to adapt. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev wrote: > Frankly I have much more faith in Tom's idea of using virtual part of the > catalog for all temporary tables, i.e turning all temporary tables into > "fast" temporary tables. Instead of introducing a new type of temporary tables > that solve catalog bloating problem and forcing users to rewrite applications > why not just not to create a problem in a first place? Would applications really need to be rewritten? Are they really constructing temporary tables where the definition of the table is dynamic, not just the content? I think application authors would be pretty happy to not need to keep recreating the same tables over and over again and dealing with DDL in their run-time code. It's not really rewriting an application to just remove that DDL and move it to the one-time database schema creation. I think it's clear we got the idea of temporary tables wrong when we implemented them and the SQL standard is more useful. It's not just some implementation artifact that it's possible to implement them in an efficient way. It's a fundamental design change and experience shows that separating DDL and making it static while the DML is dynamic is just a better design. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers