On Wed, Jul 15, 2015 at 11:52 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 15 July 2015 at 16:44, Andres Freund <and...@anarazel.de> wrote: >> On 2015-07-15 16:36:12 +0100, Simon Riggs wrote: >> > On 15 July 2015 at 16:28, Andres Freund <and...@anarazel.de> wrote: >> > > I think that's generally a fair point. But here we're discussing to >> > > add >> > > a fair amount of wrinkles with the copy approach. The fact alone that >> > > the oid is different will have some ugly consequences. >> > > >> > >> > Why? We are creating a local temp table LIKE the global temp table. That >> > is >> > already a supported operation. So there is no "different oid". >> >> Then your locking against ALTER, DROP etc. isn't going to work. > > There would be two objects, both locked. The temp table is just nice and > simple. No problem. > > Your optimization may work; I hope it does. My approach definitely will. So > we could choose either.
It's not really an optimization; it's a whole different approach. I looked at the create-a-temp-table-on-the-fly idea back when I implemented unlogged tables and concluded it was an unworkable mess. Deep down in the guts of name resolution code is not the place where you want to suddenly decide that you need to run some DDL. So I believe in what Andres is proposing. I'm not necessarily going to shout it down if somebody finds a way to make the temp-table-on-the-fly approach work, but my view is that making that work, although it may look superficially appealing, will eventually make whoever has to do it hate their life; and that even if they get it to where it sorta works, it's going to have ugly corner cases that are almost impossible to file down. Another advantage of Andres's approach, BTW, is that it could potentially eventually be extended to work on Hot Standby machines. For that to work, we'd need a separate XID space for temporary tables, but Noah proposed that before, and I don't think it's a completely crazy idea (just mostly crazy). Now, maybe nobody's going to care about that any more in 5 years if we have full-blown logical replication deeply integrated into core, but there's a lot to like about a design that keeps our options in that area open. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers