| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> | 
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> | 
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: RFC: Restructuring pg_aggregate | 
| Date: | 2002-04-12 02:26:05 | 
| Message-ID: | 200204120226.g3C2Q5I27551@candle.pha.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hiroshi Inoue wrote:
> Christopher Kings-Lynne wrote:
> > 
> > Hmmm.  Personally, I think that a DROP COLUMN that cannot reclaim space is
> > kinda useless - you may as well just use a view!!!
> > 
> > So how would this occur?:
> > 
> > 1. Lock target table for writing (allow reads)
> > 2. Begin a table scan on target table, writing
> >    a new file with a particular filenode
> > 3. Delete the attribute row from pg_attribute
> > 4. Point the table in the catalog to the new filenode
> > 5. Release locks
> > 6. Commit transaction
> > 7. Delete orhpan filenode
> > 
> > i. Upon postmaster startup, remove any orphaned filenodes
> > 
> > The real problem here is the fact that there are now missing attnos in
> > pg_attribute.  Either that's handled or we renumber the attnos - which is
> > also quite hard?
> 
> The attnos should be renumbered and it's easy.
> But the above seems only 20% of the total implementation.
> If the attnos are renumbered, all objects which refer to 
> the numbers must be invalidated or re-compiled ...
> For example the parameters of foreign key constraints
> triggers are consist of relname and colnames currently.
> There has been a proposal that change to use relid or
> column numbers instead. Certainly it makes RENAME happy
> but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3
> and the second column of the relation is dropped the
> parameter must be changed to be a_rel/1/2. If neither
> foreign key stuff nor DROP COLUMN take the other into
> account, the consistency is easily broken. 
I think that is why Tom was suggesting making all the column values NULL
and removing the pg_attribute row for the column.  With a NULL value, it
doesn't take up any room in the tuple, and with the pg_attribute column
gone, no one will see that row.  The only problem is the gap in attno
numbering.  How big a problem is that?
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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 | Christopher Kings-Lynne | 2002-04-12 02:33:44 | Re: command.c breakup | 
| Previous Message | Barry Lind | 2002-04-12 02:24:13 | Re: 7.3 schedule |