On Sun, Jan 24, 2010 at 8:36 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei <kai...@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.
Er... rename a column from A1, not drop. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers