Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: ALTER TABLE DROP COLUMN
Date
Msg-id 200006091249.IAA18730@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: ALTER TABLE DROP COLUMN  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List 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@candle.pha.pa.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: AW: Proposal: TRUNCATE TABLE table RESTRICT
Next
From: Roland Roberts
Date:
Subject: Re: Sigh, LIKE indexing is *still* broken in foreign locales