| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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: | AW: AW: ALTER TABLE DROP COLUMN |
| Date: | 2000-10-13 07:42:10 |
| Message-ID: | 11C1E6749A55D411A9670001FA6879633680A0@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
The difference for a cleanup would be, that it does not need to
be rolled back as a whole (like current vacuum).
A cleanup could be partly done, and resumed later, thus a sofisticated
cleanup could avoid 2X.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas SB | 2000-10-13 07:53:20 | AW: Inserting a select statement result into another ta ble |
| Previous Message | Cedar Cox | 2000-10-13 07:24:34 | RE: Announcing PgSQL - a Python DB-API 2.0 compliant interface to PostgreSQL |