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
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 |