Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog
 (a.k.a fast temp tables)
To: Andres Freund <andres@anarazel.de>
References: <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>
 <cc40a241-14d1-15da-90fa-e89fbc2159e3@2ndquadrant.fr>
 <2bb00def-22bf-40a1-7dfb-6e72b99a351a@2ndquadrant.com>
 <20160831214300.stlmapnudo7ifccj@alap3.anarazel.de>
Cc: Vik Fearing <vik@2ndquadrant.fr>, Robert Haas <robertmhaas@gmail.com>,
 Jim Nasby <Jim.Nasby@bluetreble.com>,
 Aleksander Alekseev <a.alekseev@postgrespro.ru>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <ff2bea21-c134-52f4-b7e4-827d6ca37f88@2ndquadrant.com>
Date: Thu, 1 Sep 2016 00:00:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101
 Thunderbird/46.0a2
MIME-Version: 1.0
In-Reply-To: <20160831214300.stlmapnudo7ifccj@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 08/31/2016 11:43 PM, Andres Freund wrote:
> On 2016-08-31 23:40:46 +0200, Tomas Vondra wrote:
>> It's an improvement (and it's pretty much exactly what I proposed
>> upthread). But it does not solve the problems with pg_statistic for
>> example (each backend needs it's own statistics. So we'd either bloat
>> the pg_statistic (if we manage to solve the problem that the table has
>> the same oid in all backends), or we would need in-memory tuples (just
>> like discussed in the thread so far).
> 
> Creating a session private version of pg_statistic would be fairly
> simple.

Sure. I'm just saying it's not as simple as overriding relpath.

ISTM we only need the pg_statistics (as other catalogs are connected to
the pg_class entry), which does not have the dependency issues. Or do we
need other catalogs?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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