Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN (was RFC: Restructuring pg_aggregate)
Date
Msg-id 15980.1018714780@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN (was RFC: Restructuring pg_aggregate)  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.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


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: DROP COLUMN (was RFC: Restructuring pg_aggregate)
Next
From: Jan Wieck
Date:
Subject: Re: numeric/decimal docs bug?