Re: Implementation of global temporary tables?

On Mon, Feb 2, 2015 at 6:34 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> 2015-02-02 13:36 GMT+01:00 Atri Sharma <atri(dot)jiit(at)gmail(dot)com>:
>
>>
>>> > 1. Main catalogue will be stable.
>>> > 2. There is not necessary to implement new storage and it can helps
>>> with
>>> > transaction support.
>>>
>>> The amount of complexity that'd be involved to store catalog data in a
>>> separate relation around the caches and accesses would be significant. I
>>> don't think that's a realistic option.
>>>
>>
>> Not to mention the problems we might end up in. We still have corner
>> cases in our cache code, and a new heap on top of it all might be just too
>> painful.
>>
>>>
>>> > > > 3.c - store ephemeral metadata only in memory without MVCC
>>> > >
>>> > > I think that's not an option. That'd end up being a massive amount of
>>> > > duplication at a low rate of functionality.
>>> > >
>>> >
>>> > I don't plan to implement a storage - I expect only few functions for
>>> > store/read data from session memory context
>>>
>>> What does it have to do with temp tables then?
>>>
>>
>> I think what Pavel means here is that we do not need a full fledged heap
>> layer and rather only a minimal API from a per session memory context.
>> However, that might be still as painful because we will eventually end up
>> inventing mechanisms for syscache and typcache to work with this storage,
>> which IMO is the biggest pain point around this idea.
>>
>
> It should be solvable - I see another risk - if we accelerate a work with
> temp tables, then 4 byte oid should not be enough.
>
>
>>
>>
Hrm, that might well be true. It might be worth the effort to find a better
way to materialize global temp tables then, like having a single OID and
only materializing a relfilenode for a session when the session inserts
into the temp table. Not sure here at all...

--
Regards,

Atri
*l'apprenant*