|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||global temporary tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Tom Lane||2010-04-24 03:11:22||Re: global temporary tables|
|Previous Message||Andrew Dunstan||2010-04-24 00:42:23||Re: vcregress.bat check triggered Heap error in the Debugversion of win32 build|