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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, 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:23:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> --On 24. Januar 2010 08:37:13 -0500 Robert Haas <robertmhaas(at)gmail(dot)com> 
> wrote:
>> I think the problem case here might be something like this...

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

I think my concern about the original proposal was that the time to
perform an ALTER RENAME would increase with the number of tables in the
database, even if they were entirely unrelated to the one you're trying
to rename.  It's not clear to me whether the present coding of the patch
avoids that.  But in any case, the alternative implementation I
suggested would have added essentially zero runtime, so even a 50%
slowdown seems like sacrificing a lot.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2010-01-24 18:25:24
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Previous:From: Magnus HaganderDate: 2010-01-24 18:21:19
Subject: Re: Resetting a single statistics counter

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