2015-02-02 13:36 GMT+01:00 Atri Sharma <atri.j...@gmail.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* >
