From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: AW: ALTER TABLE DROP COLUMN |
Date: | 2000-10-13 13:53:08 |
Message-ID: | 39E713C4.6CC93F42@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum)
>
> But the peak space usage during cleanup must still be 2X.
Perhaps he means some kind of off-line cleanup tool, that has only the
requirement of being able to continue from where it left off (or
crashed) ?
It could be useful in some cases (like removing a column on saturday
from a
terabyte-sized file that is used only on weekdays :)
----------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Moschuk | 2000-10-13 15:05:02 | -d 2 frustration |
Previous Message | Clark, Joel | 2000-10-13 12:33:53 | RE: [INTERFACES] Announcing PgSQL - a Python DB-API 2.0 compliant interface to PostgreSQL |