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

From Tom Lane
Subject Re: DROP column: documentation unclear
Date
Msg-id 22240.1268155683@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP column: documentation unclear  (Harald Fuchs <hari.fuchs@gmail.com>)
List pgsql-general
Harald Fuchs <hari.fuchs@gmail.com> writes:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>> 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.

> But if you already have eight nullable columns, the (maybe originally
> non-null) column which has been dropped would cause the header to be
> one byte larger, wouldn't it?

No; the size of the bitmap is equal to the total number of columns, not
the number of columns that are null.  One way to think about it is that
the first null in a particular row costs NUMCOLUMNS bits to store, and
then any additional nulls are free.

Anyway, arguing about the size of the null bitmap seems to me to be
beside the point.  If you care about the space occupied by a column at
all, it's going to be a lot more than one bit.  It's that macroscopic
space usage that the DROP COLUMN documentation is talking about
reclaiming, not whether or not you need a null bitmap.

            regards, tom lane

pgsql-general by date:

Previous
From: Steve Coleman
Date:
Subject: question on 8.4.2 build postgres C functions
Next
From: Thomas Kellerer
Date:
Subject: Re: \copy command: how to define a tab character as the delimiter