Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog
 (a.k.a fast temp tables)
To: Vik Fearing <vik@2ndquadrant.fr>, Robert Haas <robertmhaas@gmail.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>
 <cc40a241-14d1-15da-90fa-e89fbc2159e3@2ndquadrant.fr>
Cc: 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: <2bb00def-22bf-40a1-7dfb-6e72b99a351a@2ndquadrant.com>
Date: Wed, 31 Aug 2016 23:40:46 +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: <cc40a241-14d1-15da-90fa-e89fbc2159e3@2ndquadrant.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 08/31/2016 09:20 PM, Vik Fearing wrote:
> 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?
> 

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).


-- 
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