On Wed, Jul 15, 2015 at 11:52 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 15 July 2015 at 16:44, Andres Freund <andres@anarazel.de> wrote:
>> On 2015-07-15 16:36:12 +0100, Simon Riggs wrote:
>> > On 15 July 2015 at 16:28, Andres Freund <andres@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