Re: DROP column: documentation unclear - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: DROP column: documentation unclear
Date
Msg-id 20100308213549.GB660@svana.org
Whole thread Raw
In response to DROP column: documentation unclear  (Adrian von Bidder <avbidder@fortytwo.ch>)
Responses autovacuum question  ("Scot Kreienkamp" <SKreien@la-z-boy.com>)
List pgsql-general
On Mon, Mar 08, 2010 at 05:09:14PM +0100, Adrian von Bidder wrote:
> Hi,
>
> The documentation about DROP COLUMN is a bit unclear:
>
> | The DROP COLUMN form does not physically remove the column, but simply
> | makes it invisible to SQL operations. Subsequent insert and update
> | operations in the table will store a null value for the column. Thus,
> | dropping a column is quick but it will not immediately reduce the on-disk
> | size of your table, as the space occupied by the dropped column is not
> | reclaimed. The space will be reclaimed over time as existing rows are
> | updated.
>
> "subsequent ... will store a null value" would imply that deleted columns
> will still take some place, while "the space will be reclaimed ..." would
> suggest that new rows (insert or updates in mvcc) don't have the deleted
> column anymore - I'm not quite sure how to interpret this.  What is pg
> doing?

What you're missing is that in postgres NULLs are stored as a bit in
the header and there is no data. So in a sense NULLs take no space
(well, one bit) which means both statements are true.

Have a nice day,

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Attachment

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: managing tablespaces like files?
Next
From: Sam Carleton
Date:
Subject: Re: managing tablespaces like files?