Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx?

On Thu, May 21, 2009 at 6:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Sam Mason <sam(at)samason(dot)me(dot)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.