Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
От | KaiGai Kohei |
---|---|
Тема | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns |
Дата | |
Msg-id | 4B5CDBA2.4080600@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns (Bernd Helmle <mailings@oopsware.de>) |
Ответы |
Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO
on inherited columns
|
Список | pgsql-hackers |
(2010/01/25 4:01), Bernd Helmle wrote: > > > --On 24. Januar 2010 19:45:33 +0100 Bernd Helmle <mailings@oopsware.de> > wrote: > >> I don't see where this should be related to the number of tables not >> part of the inheritance tree (or inheritance at all). > > To answer that myself: it seems get_attname() introduces the overhead > here (forgot about that). Creating additional 16384 tables without any > connection to the inheritance increases the times on my Phenom-II Box to > round about 2 seconds: > > > Current -HEAD > > bernd=# ALTER TABLE a1 RENAME COLUMN acol1 TO xyz; > ALTER TABLE > Time: 409,045 ms > > > With KaiGai's recent patch: > > bernd=# ALTER TABLE a1 RENAME COLUMN acol1 TO xyz; > ALTER TABLE > Time: 2402,306 ms Hmm.... Bernd, could you try same test with previous patch? http://archives.postgresql.org/message-id/4B41BB04.2070609@ak.jp.nec.com It computes an expected inhcount during find_all_inheritors(), and compares it with the target pg_attribute entry? I'll also try to measure performance in three cases by myself. Please wait for a while... Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: