| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Wojciech Strzałka <wstrzalka(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Problem with TOAST tables when removing TOASTable column |
| Date: | 2008-05-14 16:22:29 |
| Message-ID: | 20859.1210782149@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
=?iso-8859-2?Q?Wojciech_Strza=B3ka?= <wstrzalka(at)gmail(dot)com> writes:
>> To make that happen would require (at least) a full table scan. I think
>> most people are more interested in DROP COLUMN being a cheap operation
>> than in having the space be reclaimed quickly.
>> For a comparison point: large field values that don't happen to get
>> toasted don't vanish immediately, either.
> I agree DROP COLUMN should be cheap and I don't really expect it to happend immediately,
> but shouldn't VACUUM FULL clean it up?
No, changing the content of existing tuples is outside VACUUM's purview.
FWIW, I believe that a CLUSTER would clean it up, and would likely be
faster than a VACUUM FULL anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Francisco Leovey | 2008-05-14 19:06:03 | BUG #4168: ECPG refuses datestyle SQL |
| Previous Message | Tom Lane | 2008-05-14 16:14:20 | Re: BUG #4167: When generating UUID using UUID-OSSP module, UUIDs are not unique on Windows |