DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	b=FdRutVOFK1qNMmGNDnePwv3d/rKWYcszOu/y//ABXVBc6pmJ3skh/LSwhUoqUfslfA
	Ji6bMBx3tu58ncBamtOvNoEPiEg706dZoQWbNPpmFRrWHp8jtOY2e7ONd9KTIY3Aj7HE
	cSQA93AowV0VBTtB1Dutv6Bt03aAuvp0djknw=
MIME-Version: 1.0
Date: Fri, 23 Apr 2010 22:52:41 -0400
Message-ID: <u2o603c8f071004231952i36642ae6u9d6a7eae6eb6ff32@mail.gmail.com>
Subject: global temporary tables
From: Robert Haas <robertmhaas@gmail.com>
To: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1

A couple of recent threads made got me thinking again about the idea
of global temporary tables.  There seem to be two principal issues:

1. What is a global temporary table?

2. How could we implement that?

Despite rereading the "idea: global temp tables" thread from April
2009 in some detail, I was not able to get a clear understanding of
(1).  What I *think* it is supposed to mean is that the table is a
permanent object which is "globally" visible - that is, it's part of
some non-temp schema like public or $user and it's column definitions
etc. are visible to all backends - and it's not automatically removed
on commit, backend exit, etc. - but the *contents* of the table are
temporary and backend-local, so that each new backend initially sees
it as empty and can then insert, update, and delete data independently
of what any other backend does.

As to (2), my thought is that perhaps we could implement this by
instantiating a separate relfilenode for the relation for each backend
which accesses it.  relfilenode would be 0 in pg_class, as it is for
"mapped" relations, but every time a backend touched the rel, we'd
allocate a relfilenode and associated the oid of the temp table to it
using some kind of backend-local storage - actually similar to what
the relmapper code does, except without the complexity of ever
actually having to persist the value; and perhaps using a hash table
rather than an array, since the number of mapped rels that a backend
can need to deal with is rather more limited than the number of temp
tables it might want to use.

Thoughts?

...Robert