On Thu, May 21, 2009 at 6:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Sam Mason <s...@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". > > No, it isn't. It's because each tuple includes the actual count of > 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.
