Re: ALTER TABLE DROP COLUMN
От | The Hermit Hacker |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | Pine.BSF.4.21.0010072107500.1627-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE DROP COLUMN
|
Список | 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?
В списке pgsql-hackers по дате отправления: