Re: global temporary tables

On Sat, Apr 24, 2010 at 3:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ...  Why would the
>> end-of-session processing need the catalog entries?  It seems like
>> whatever backend-local data structure we're using to record the
>> relfilenode mappings would be sufficent to nuke the backend storage,
>> and what else needs doing?
>
> Well, if you're intending to have a separate data structure and code
> path for cleaning up this type of temp table, then maybe you don't need
> to touch any catalog entries.  I'm concerned though about how far the
> effects will propagate --- things like TRUNCATE, VACUUM FULL, REINDEX
> will probably have issues with this.  Right now they think in terms
> of writing a new pg_class entry in order to reassociate tables with
> new relfilenodes.
>
> Have you thought much about the previously proposed design, ie keeping
> catalog entries for temp tables in backend-local temporary catalogs?
> That would certainly be a lot of work, but I think in the end it might
> fit in better.  This design feels like it's being driven by "hey,
> we can abuse the relmapper to sort of do what we want", and not by
> what we really want.

Well, yes and no.  I think there are definitely some good things that
can happen if we can see our way to taking a hammer to pg_class and
pg_attribute.  If we create, e.g. pg_shared_class and
pg_shared_attribute, then we can un-nail the catalogs you just nailed
to make the authentication process able to work without selecting a
database.  We can also enable (without guilt) clustering both those
catalogs and the database-specific versions of pg_class, since we no
longer have to worry about having multiple copies of the row that can
get out of sync with each other.  And if we further break off
pg_temp_class and pg_temp_attribute, then we can also have our
existing flavor of temporary tables without worrying about catalog
bloat, which would be great.  There may be other applications as well.

Having said all that, it doesn't actually allow us to implement global
temporary tables, because obviously the catalog entries for a global
temporary table have to be permanent.  Of course, if we didn't have to
worry about catalog bloat, the "clone" approach you're proposing would
be somewhat more attractive, but I actually think that the synergy is
in the other direction: the perfect place to store the catalog entries
and statistics for local temporary tables is - in a global temporary
table!  Note that while a local temporary table can never inherit from
a permanent table, it's entirely sensible to let global temporary
tables inherit from permanent tables.  Different backends will have
different views of the overall contents of the parent table, but
that's OK, even desirable.

...Robert