Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: 2000-02-28 14:29:29
Message-ID: 3.0.1.32.20000228062929.00fbd4c0@mail.pacifier.com (view raw or flat)
Thread:
Lists: 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(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-02-28 14:40:01
Subject: Re: [HACKERS] A further thought on rule string size
Previous:From: Don BaccusDate: 2000-02-28 14:21:41
Subject: Re: [HACKERS] A further thought on rule string size

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group