Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
От | Pavel Stehule |
---|---|
Тема | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
Дата | |
Msg-id | CAFj8pRBgZ+Jec+V1zVbN+JY7mMxeJsoUZyW6DmfcVFUpxDzROg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
2016-08-18 16:33 GMT+02:00 Tomas Vondra <tomas.vondra@2ndquadrant.com>:
On 08/15/2016 12:23 PM, Pavel Stehule wrote:
2016-08-15 12:18 GMT+02:00 Aleksander Alekseev
<a.alekseev@postgrespro.ru <mailto:a.alekseev@postgrespro.ru>>:
> The global temporary tables has persistent rows in the catalogue. The
> mapping to files can be marked as special and real mapping should be
> only in memory.
>
> So the changes in catalogue related to global temporary tables are
> pretty less frequently.
I'm afraid I still don't get it. Let say I have an application that
does `CREATE TEMP TABLE xx ; DROP TABLE xx` in every session all the
time. Naturally there is not only one temp table per session. Could you
explain please in more detail how exactly do these persistent rows help?
when you use global temporary tables, then you create it only once -
like usual tables.
you don't drop these tables.
I share the view that this is a better/simpler solution to the problem. It will still require virtual (in-memory) tuples for pg_statistic records, but everything else works pretty much as for regular tables. In particular there are no problems with dependencies.
The obvious disadvantage is that it requires changes to applications.
sure - as plpgsql developer I can say, the global temp tables are much more friendly - so rewriting in application is enjoy work.
Regards
Pavel
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: