2010/10/19 Greg Stark <gsstark@mit.edu>:
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas <robertmhaas@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
>
