Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date
Msg-id 603c8f071001240536l48da7b5fj7180851078ac661a@mail.gmail.com
Whole thread Raw
In response to Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> (2010/01/24 12:29), Robert Haas wrote:
>> I don't think this is ready for committer, becauseTom previously
>> objected to the approach taken by this patch here, and no one has
>> answered his objections:
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00144.php
>>
>> I think someone needs to figure out what the worst-case scenario for
>> this is performance-wise and submit a reproducible test case with
>> benchmark results.  In the meantime, I'm going to set this to Waiting
>> on Author.
>
> Basically, I don't think it is not a performance focused command,
> because we may be able to assume ALTER TABLE RENAME TO is not much
> frequent operations.

I agree - the requirements here are much looser than for, say, SELECT
or UPDATE.  But it still has to not suck.

I think the problem case here might be something like this...  create
ten tables A1 through A10.  Now create 10 more tables B1 through B10
each of which inherits from all of A1 through A10.  Now create 10 more
tables C1 through C10 that inherit from B1 through B10.  Now create
1000 tables D1 through D1000 that inherit from C1 through C10.  Now
drop a column from A1.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: further explain changes
Next
From: Robert Haas
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns