Re: MaxOffsetNumber for Table AMs

On Mon, 2021-05-03 at 13:22 -0400, Robert Haas wrote:
> to look and work like heap TIDs; that is, there had better be a block
> number portion and an item number portion,

Right (at least for now).

> and the item number had
> better be smaller than MaxOffsetNumber,

That's not clear to me at all, and is the whole reason I began this
thread.

a. You say "smaller than MaxOffsetNumber", but that's a little weird.
If an offset can't be MaxOffsetNumber, it's not really the maximum, is
it?
b. If you actually meant "less than or equal to MaxOffsetNumber",
that will fail with the GIN posting list issue raised in my first
email. Do you agree that's a bug?
c. Why can't we go all the way up to MovedPartitionsOffsetNumber - 1?
Right now, MaxOffsetNumber is poorly named, because it actually
represents the a number slightly higher than the maximum number of
items that can fit on a page. That essentially wastes 5 bits of address
space for no obvious reason.

> and if you want bitmap scans
> to run reasonably quickly, the block number had also better
> correspond
> to physical locality to some degree.

Right (at least for now).

Regards,
Jeff Davis