| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) |
| Date: | 2002-04-13 16:19:40 |
| Message-ID: | 15980.1018714780@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
>> No, VACUUM has the same transactional constraints as everyone else
>> (unless you'd like a crash during VACUUM to trash your table...)
> But can't it do the SET TO NULL thing if it knows that the transaction
> that dropped the column has committed.
Hmm, you're thinking of allowing VACUUM to overwrite tuples in-place?
Strikes me as unsafe, but I'm not really sure.
In any case it's not that easy. If the column is wide enough
that reclaiming its space is actually worth doing, then presumably
most of its entries are just TOAST links, and what has to be done is
not just rewrite the main tuple but mark the TOAST rows deleted.
This is not something that VACUUM does now; I'd be rather concerned
about the locking implications (especially for lightweight VACUUM).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2002-04-13 16:47:07 | Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) |
| Previous Message | Tom Lane | 2002-04-13 15:46:01 | Re: 7.3 schedule |