Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: ALTER TABLE DROP COLUMN (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
|
Список | pgsql-hackers |
At 11:45 AM 2/28/00 +0200, Hannu Krosing wrote: >"update t set id=id+1" is also a 2x space, And PG doesn't do it correctly anyway... > likely even more if >referential inheritance is used (and checked at the end of transaction) The triggers are all queued so yes, take memory too. Even better, if "MATCH <unspecified>" or especially "MATCH PARTIAL" is used with multi-column foreign keys containing nulls, it will be impressively slow! We can call these the built-in coffee break feature when used on large tables. (it's inherently slow, not just slow because of the PG implementation) >And my main use of DROP COLUMN will probably be during development, >usually meaning small table sizes. Well, folks who use the web toolkit I've been porting for Oracle will have a use for it, too, because the toolkit has been rapidly evolving (ArsDigita has about 70 employees at the moment, most of them programmers working on the Oracle-based version of the toolkit). ArsDigita provides upgrade .sql files for each version that consist in part of ADD/DROP column statements so users can upgrade in place, a very useful thing. It doesn't need to be fast in this context, just work. You tell the world your site will be down for an evening on such-and-such date, stop listening on port 80, and upgrade. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: