Re: Another idea for dealing with cmin/cmax
От | Heikki Linnakangas |
---|---|
Тема | Re: Another idea for dealing with cmin/cmax |
Дата | |
Msg-id | 451CF08F.9080902@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Another idea for dealing with cmin/cmax (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
Martijn van Oosterhout wrote: > 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? No, you'd still have the the number of attributes (t_natts) in the header. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: