Re: MaxOffsetNumber for Table AMs

On Mon, May 3, 2021 at 1:00 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> You don't accept any of that, though. Fair enough. I predict that
> avoiding making a hard choice will make Jeff's work here a lot harder,
> though.

I don't really think so, or at least I don't see a reason why it
should. As things stand today, I don't think it's possible for a table
AM author to make any other choice than to assume that their TIDs have
to look and work like heap TIDs; that is, there had better be a block
number portion and an item number portion, and the item number had
better be smaller than MaxOffsetNumber, and if you want bitmap scans
to run reasonably quickly, the block number had also better correspond
to physical locality to some degree. It's not clear to me how exactly
someone would go about fixing all of that, but I think it would be
great if they did. Even if that person wanted to assume for purposes
of their own patch that fixed-width, integer-like TIDs are the only
thing we care about, that would be fine with me. Getting to a point
where the available 48 bits can be used in whatever way the table AM
author wants is clearly better than what we have now.

Now I'm personally of the opinion that we shouldn't be content to stop
there, but so what? I'm not insisting that Jeff or anyone else has to
work on this problem, or that they have to fix more of it rather than
less. I hope that nobody's going to try to back us into a corner by
making design decisions that deliberately complicate the possibility
of future improvements in that area, and that's about it. I don't
really understand why you think that's unreasonable, or even
problematic. I can't see that any way in which the assumption that we
will NEVER want to further generalize the TID concept simplifies
anything anyone wants to do today.

--
Robert Haas
EDB: http://www.enterprisedb.com