Thread: MaxOffsetNumber versus MaxHeapTuplesPerPage

Is there any reason to have both these macros? By my opinion 
MaxHeapTuplesPerPage is more accurate and it should replace all 
MaxOffsetNumber occurrence.
Any comments?
    Zdenek

http://doxygen.postgresql.org/htup_8h.html#c8829334a53a69e12b070bf09b7b7ab7
http://doxygen.postgresql.org/off_8h.html#fc094b61f53a883c7a24bc152382cd31

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.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

Heikki Linnakangas wrote:
> 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.

I forgot to indexes, but there is MaxIndexTuplesPerPage which is also 
better estimation for indexes.

> 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.

Yes, it is a cleanup (maybe reduce some memory requirements), but I 
think is better to reduce different macros to avoid future problem, when 
somebody forget changes all of these macros.
    Zdenek

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