On Mon, Feb 2, 2015 at 6:34 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > > 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. > > >> >> 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*
