MaxOffsetNumber versus MaxHeapTuplesPerPage

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