Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date
Msg-id CAM-w4HODNfBN+k3C9xNeJX=ESYybZGRV7jmHuMk+_+i+C6KJCg@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Responses Re: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> 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



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Next
From: neha khatri
Date:
Subject: Re: New SQL counter statistics view (pg_stat_sql)