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.