Re: Implementation of global temporary tables?

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.

>
>
> Regards,
>
> Atri
>
> Regards,
>
> Atri
> *l'apprenant*
>