Re: AW: ALTER TABLE DROP COLUMN

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

In response to

Browse pgsql-hackers by date

  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