Re: ALTER TABLE DROP COLUMN
Marc G. Fournier <scrappy@hub.org>
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Date: 2000-10-08T00:11:55Z
Lists: pgsql-hackers
On Thu, 5 Oct 2000, Tom Lane wrote: > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > Seems some people expect the implementation in 7.1. > > (recent [GENERAL} drop column?) > > I could commit my local branch if people don't mind > > backward incompatibility. there have been several ideas thrown back and forth ... the best one that I saw, forgetting who suggested it, had to do with the idea of locking the table and doing an effective vacuum on that table with a 'row re-write' happening ... Basically, move the first 100 rows to the end of the table file, then take 100 and write it to position 0, 101 to position 1, etc ... that way, at max, you are using ( tuple * 100 ) bytes of disk space, vs 2x the table size ... either method is going to lock the file for a period of time, but one is much more friendly as far as disk space is concerned *plus*, if RAM is available for this, it might even be something that the backend could use up to -S blocks of RAM to do it off disk? If I set -S to 64meg, and the table is 24Meg in size, it could do it all in memory?