Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
От | Bernd Helmle |
---|---|
Тема | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns |
Дата | |
Msg-id | 5A1520A3F5065BB53AF6CEC0@amenophis обсуждение исходный текст |
Ответ на | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
|
Список | pgsql-hackers |
--On 24. Januar 2010 08:37:13 -0500 Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: