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