2010/10/19 Greg Stark <gsst...@mit.edu>: > On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas <robertmh...@gmail.com> wrote: >> The trick is that it would require us to have two pg_class tables, two >> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one >> permanent and one temporary. I am not sure how complex that will turn >> out to be. > > Tom suggested using inheritance for this. > > I find it strange to try constructing catalog tables to represent > these local definitions which never need to be read by any other > backend and in any case are 1:1 copies of the global catalog entries. > > It seems to me simpler and more direct to just nail relcache > entries for these objects into memory and manipulate them directly. > They can be constructed from the global catalog tables and then > tweaked to point to the backend local temporary tables. >
+1 I had very ugly implementation of global temp tables based just on relcache. The "only" one problem was with refresh of relcache. But it's not too easy - for real using it's necessary to overwrite - statistics, indexes, access statistics. I had a idea to modify a data pages cache for support a permanent (and only memory) pages. Then we can have a temporal tuples together with standard tuples in one system table. This can be similar to memory tables in mysql and can be interesting in cooperation with mmap - very fast access to some tables or pre readed tables. Regards Pavel > -- > greg > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers