| From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, 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-12 18:06:43 |
| Message-ID: | Pine.BSF.4.21.0010121501190.4709-100000@thelab.hub.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 12 Oct 2000, 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.
Is there no way of doing this such that we have N tuple types in the
table? So that UPDATE/INSERTs are minus the extra column, while the old
ones just have that column marked as deleted? Maybe change the stored
value of the deleted field as some internal value that, when vacuum, or
any other operation, sees it, it 'ignores' that field? maybe something
that when you do an 'alter table drop', it effectively does an UPDATE on
that field to set it to the 'drop column' value?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David J. MacKenzie | 2000-10-12 18:09:03 | Re: [PATCHES] PostgreSQL virtual hosting support |
| Previous Message | Dan Moschuk | 2000-10-12 17:56:10 | Re: Core dump |