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

From Jim Nasby
Subject Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Date
Msg-id 95bdc353-1a89-3fe3-1181-eba558c4df83@BlueTreble.com
Whole thread Raw
In response to Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 8/16/16 11:59 AM, Robert Haas wrote:
...
> That doesn't really solve the problem, because OTHER backends won't be
> able to see them.  So, if I create a fast temporary table in one
> session that depends on a permanent object, some other session can
> drop the permanent object.  If there were REAL catalog entries, that
> wouldn't work, because the other session would see the dependency.

Some discussion about TEMP functions is happening on -general right now, 
and there's other things where temp objects are good to have, so it'd be 
nice to have a more generic fix for this stuff. Is the idea of 
"partitioning" the catalogs to store temp objects separate from 
permanent fatally flawed?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: anyelement -> anyrange
Next
From: Tom Lane
Date:
Subject: Re: Keeping CURRENT_DATE and similar constructs in original format