Re: DROP column: documentation unclear

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: DROP column: documentation unclear
Date: 2010-03-09 17:28:03
Message-ID: 22240.1268155683@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Harald Fuchs <hari(dot)fuchs(at)gmail(dot)com> writes:
> Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2010-03-09 17:30:16 Re: \copy command: how to define a tab character as the delimiter
Previous Message Steve Coleman 2010-03-09 17:23:46 question on 8.4.2 build postgres C functions