Skip site navigation (1) Skip section navigation (2)

Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Thom Brown <thombrown(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date: 2010-01-24 18:09:54
Message-ID: 5A1520A3F5065BB53AF6CEC0@amenophis (view raw or flat)
Thread:
Lists: pgsql-hackers

--On 24. Januar 2010 08:37:13 -0500 Robert Haas <robertmhaas(at)gmail(dot)com> 
wrote:

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

Yeah, i think the meaning of "suck" can be much weakier than for a DML
command. However, if it would degrade the performance of a formerly well 
running command in a way, that it would be unusable, that would be annoying.

>> 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.
>
> Er... rename a column from A1, not drop.
>

Did that with a crude pl/pgsql script, and got the following numbers:

Current -HEAD:

Phenom-II 2.6 GHz: Time: 282,471 ms
MacBook: Time: 499,866 ms

With KaiGais recent patch (which covers the TYPE case, too):

Phenom-II 2.6 GHz: Time: 476,800 ms
MacBook: Time: 753,161 ms


-- 
Thanks

	Bernd

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-24 18:13:52
Subject: Re: Resetting a single statistics counter
Previous:From: Tom LaneDate: 2010-01-24 18:06:16
Subject: Re: Largeobject Access Controls (r2460)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group