vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| =?iso-8859-2?Q?Wojciech_Strza=B3ka?= <wstrzalka@gmail.com> writes: > In my opinion the fact that dropping column doesn't release it's toastable resources is a bug. 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. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs |
| |||
| > 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? Wojtek Strzalka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs |
| ||||
| =?iso-8859-2?Q?Wojciech_Strza=B3ka?= <wstrzalka@gmail.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs |