Re: Another idea for dealing with cmin/cmax
От | Martijn van Oosterhout |
---|---|
Тема | Re: Another idea for dealing with cmin/cmax |
Дата | |
Msg-id | 20060929100515.GB8702@svana.org обсуждение исходный текст |
Ответ на | Re: Another idea for dealing with cmin/cmax (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Another idea for dealing with cmin/cmax
|
Список | pgsql-hackers |
On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote: > Martijn van Oosterhout wrote: > >On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote: > >>We could get rid of t_hoff, because we should always be able to > >>calculate the header size. Then we're down to 18 bytes. > > > >Without t_hoff, how do you know the size of the null bitmap? You could > >probably do it only if you assume the null bitmap, if present, always > >covers all the columns... > > I think we assume that already. heap_form_tuple reserves space for the > bitmap like this: > > if (hasnull) > len += BITMAPLEN(numberOfAttributes); Ok, now we do an ALTER TABLE blah ADD COLUMN ..., and we have to expand the bitmaps for the entire table? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: