Re: ALTER TABLE DROP COLUMN
От | Bruce Momjian |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 200006091249.IAA18730@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] ALTER TABLE DROP COLUMN (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: ALTER TABLE DROP COLUMN
|
Список | 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 по дате отправления: