From: | Dmitry Koterov <dmitry(at)koterov(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fast ALTER TABLE ... ADD COLUMN ... DEFAULT xxx? |
Date: | 2009-05-28 16:16:18 |
Message-ID: | d7df81620905280916t6975c1a1l83d512227987dae8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Dmitry Koterov <dmitry(at)koterov(dot)ru> writes:
> > 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)
>
> You are wrong --- t_natts would be six here. In general the length of
> the null bitmap in a tuple (if it has one at all) is always exactly
> equal to its t_natts value.
>
And so, the real number of values in the tuple - (1, 2, 3) above - is equal
to the number of 1-bits in NULL bitmap. And the size of NULL bitmap is held
in t_natts. I meant that when I said "thanks to NULL bitmap, adding a new
nullable column is cheap". :-) And, of course, thanks to t_natts
(HeapTupleHeaderGetNatts macro) - too.
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2009-05-28 16:16:35 | Re: Clean shutdown and warm standby |
Previous Message | Markus Wanner | 2009-05-28 16:10:16 | Re: PostgreSQL Developer meeting minutes up |