On Sat, Apr 24, 2010 at 3:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
