From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: ALTER TABLE DROP COLUMN |
Date: | 2000-06-09 12:49:29 |
Message-ID: | 200006091249.IAA18730@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Seems we have 4 DROP COLUMN ideas:
Method Advantage
-----------------------------------------------------------------
1 invisible column marked by negative attnum fast
2 invisible column marked by is_dropped column fast
3 make copy of table without column col removed
4 make new tuples in existing table without column col removed
Folks, we had better choose one and get started.
Number 1 Hiroshi has ifdef'ed out in the code. Items 1 and 2 have
problems with backend code and 3rd party code not seeing the dropped
columns, or having gaps in the attno numbering. Number 3 has problems
with making it an atomic operation, and number 4 is described below.
---------------------------------------------------------------------------
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > You can exclusively lock the table, then do a heap_getnext() scan over
> > the entire table, remove the dropped column, do a heap_insert(), then a
> > heap_delete() on the current tuple, making sure to skip over the tuples
> > inserted by the current transaction. When completed, remove the column
> > from pg_attribute, mark the transaction as committed (if desired), and
> > run vacuum over the table to remove the deleted rows.
>
> Hmm, that would work --- the new tuples commit at the same instant that
> the schema updates commit, so it should be correct. You have the 2x
> disk usage problem, but there's no way around that without losing
> rollback ability.
>
> A potentially tricky bit will be persuading the tuple-reading and tuple-
> writing subroutines to pay attention to different versions of the tuple
> structure for the same table. I haven't looked to see if this will be
> difficult or not. If you can pass the TupleDesc explicitly then it
> shouldn't be a problem.
>
> I'd suggest that the cleanup vacuum *not* be an automatic part of
> the operation; just recommend that people do it ASAP after dropping
> a column. Consider needing to drop several columns...
>
> regards, tom lane
>
> ************
>
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-09 14:31:50 | Re: freefuncs.c is never called from anywhere!? |
Previous Message | Bruce Momjian | 2000-06-09 12:40:21 | Re: [HACKERS] Re: Patch for more readable parse error messages |