On Thu, May 21, 2009 at 6:45 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Sam Mason <
sam@samason.me.uk> writes:
> On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
>> ALTER TABLE ... ADD COLUMN ... NULL;
>>
>> (nullable without a default value). This is because of NULL bitmap in
>> tuples. And it's greatest feature for a developer!
> I don't think this is because of the "NULL bitmap".
fields it contains (t_natts or HeapTupleHeaderGetNatts), and the value
extraction routines are coded to assume that references to fields
beyond that number should yield NULL. So the ALTER can just leave
the existing rows alone --- only when you update a row will it change
to include the newly added field(s).
No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL):
- the corresponding NULL bitmap is (100110...)
- the corresponding tuple is (1, 2, 3)
- t_natts=3 (if I am not wrong here)
And in case of the row (5, 6, NULL, 7, 8, 9):
- the corresponding NULL bitmap is (110111...)
- the corresponding tuple is (5, 6, 7, 9)
- t_natts=4
So, without a NULL bitmap, we cannot handle this kind of rows at all by t_natts only. And the NULL bitmap plays very important role in tuple saving, and I meant exactly that point.
