Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog
 (a.k.a fast temp tables)
To: Robert Haas <robertmhaas@gmail.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>
References: <20160801124531.66cde374@fujitsu>
 <26c3bc60-6613-e7ab-517a-53136f01fb6c@2ndquadrant.com>
 <13191.1470072250@sss.pgh.pa.us> <20160804151451.6fb87507@fujitsu>
 <CA+Tgmob+AS4vPA-wp+KevL7q+qK4c7yZ5wjGvEv6EqPChE2oYQ@mail.gmail.com>
 <CA+q6zcVLO7VoHHpRn9ExkiWksF6TwJ-rabqgwRJgC2_ci8_UEQ@mail.gmail.com>
 <CA+TgmoYstEXxa0KCAPVAVseTwBpb51t=bK1FBU8L8h4sC3XWBQ@mail.gmail.com>
 <14212.1470595566@sss.pgh.pa.us>
 <20160815005755.gswdyjfob7dzw4yp@alap3.anarazel.de>
 <20319.1471223097@sss.pgh.pa.us>
 <20160815010852.5ijua2wm2edzimd4@alap3.anarazel.de>
 <20160815121216.46bd758d@e733>
 <CA+TgmoaTbFPTWEzccd1p6k_v7WwmYGwMOZ3qJYhfQo0-JmyhNQ@mail.gmail.com>
 <95bdc353-1a89-3fe3-1181-eba558c4df83@BlueTreble.com>
 <CA+TgmobRoPj2c9W9g23yeiCZu9ggFGkG8reDhFz8RCON_gMTYg@mail.gmail.com>
 <d6adce51-96f4-c508-d0dc-5311cfb223b6@2ndquadrant.com>
 <CA+TgmobxATg56djCu-Uv2s=NW=RxOeXLRsBGqaraa+c6+NbN-A@mail.gmail.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>,
 Aleksander Alekseev <a.alekseev@postgrespro.ru>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Vik Fearing <vik@2ndquadrant.fr>
Message-ID: <cc40a241-14d1-15da-90fa-e89fbc2159e3@2ndquadrant.fr>
Date: Wed, 31 Aug 2016 21:20:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmobxATg56djCu-Uv2s=NW=RxOeXLRsBGqaraa+c6+NbN-A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 08/24/2016 06:16 PM, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> Could someone please explain how the unlogged tables are supposed to fix the
>> catalog bloat problem, as stated in the initial patch submission? We'd still
>> need to insert/delete the catalog rows when creating/dropping the temporary
>> tables, causing the bloat. Or is there something I'm missing?
> 
> No, not really.  Jim just asked if the idea of partitioning the
> columns was completely dead in the water, and I said, no, you could
> theoretically salvage it.  Whether that does you much good is another
> question.
> 
> IMV, the point here is that you MUST have globally visible dependency
> entries for this to work sanely.  If they're not in a catalog, they
> have to be someplace else, and backend-private memory isn't good
> enough, because that's not globally visible.  Until we've got a
> strategy for that problem, this whole effort is going nowhere - even
> though in other respects it may be a terrific idea.

Why not just have a regular-looking table, with a "global temporary"
relpersistence (I don't care which letter it gets) and when a backend
tries to access it, it uses its own private relfilenode instead of
whatever is in pg_class, creating one if necessary.  That way the
structure of the table is fixed, with all the dependencies and whatnot,
but the content is private to each backend.  What's wrong with this idea?
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers