Re: PROPOSAL: Fast temporary tables

2016-03-01 20:17 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 3/1/16 10:05 AM, Atri Sharma wrote:
>
>> Fair point, that means inventing a whole new OID generation structure..
>>
>
> Generation is just the tip of the iceberg. You still need the equivalent
> to foreign keys (ie: pg_depend). While you would never have a permanent
> object depend on a temp object, the reverse certainly needs to be supported.
>
> If I were attempting to solve this at a SQL level, I'd be thinking about
> using table inheritance such that the permanent objects are stored in a
> permanent parent. New backends would create UNLOGGED children off of that
> parent. There would be a pid column that was always NULL in the parent, but
> populated in children. That means children could use their own local form
> of an OID. When a backend terminates you'd just truncate all it's tables.
>

> Actually translating that into relcache and everything else would be a
> serious amount of work.
>

you have to store some metadata outside catalogue - in this moment is not
important the syntax or architecture (global temp tables or fast temp
children tables). You have not to use catalogue (when you use catalogue,
then you have bloating). But these special information are related mostly
to planner and should not be MVCC (number of pages, rows, statistics), and
because we are talking about temp tables, you can use session memory.

Regards

Pavel

> --
> 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
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>