Re: MaxOffsetNumber versus MaxHeapTuplesPerPage
От | Tom Lane |
---|---|
Тема | Re: MaxOffsetNumber versus MaxHeapTuplesPerPage |
Дата | |
Msg-id | 15674.1193323704@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: MaxOffsetNumber versus MaxHeapTuplesPerPage (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas <heikki@enterprisedb.com> writes: > Zdenek Kotala wrote: >> Is there any reason to have both these macros? By my opinion >> MaxHeapTuplesPerPage is more accurate and it should replace all >> MaxOffsetNumber occurrence. > We use MaxOffsetNumber with index pages as well. > At quick glance, the only places I can see where we could replace > MaxOffsetNumber with MaxHeapTuplesPerPage, are in vacuum.c and > vacuumlazy.c, where we allocate arrays big enough to hold potentially a > full page's worth of tuples. We could change those, but it's hardly > worth the trouble. There is also a difference in intent: MaxOffsetNumber is selected so that it's physically impossible to have more than that many offsets on a page, and so it's safe to use an array sized that way without any overflow checks. MaxHeapTuplesPerPage is the most that *should* be there but one can think of corner cases where there could be more (eg, limit on number of redirect pointers hasn't been enforced correctly, not to mention flat-out corrupt page). If there is any code using MaxHeapTuplesPerPage as an array size and not backstopping it with an explicit overflow check, that would be a bug IMHO. regards, tom lane
В списке pgsql-hackers по дате отправления: