Re: MaxOffsetNumber for Table AMs

On Mon, 2021-05-03 at 15:07 -0700, Peter Geoghegan wrote:
> It seems senseless to *require* table AMs to support something like a
> bitmap scan.

I thought about this some more, and this framing is backwards.
ItemPointers are fundamental to the table AM API: they are passed in to
required methods, and expected to be returned[1].

Bitmap scans are optional, but that should be determined by whether the
author wants to implement the bitmap scan methods of their table AM.
The fine details of ItemPointer representation should not be making the
decision for them.

We still need to answer the core question that started this thread:
what the heck is an ItemPointer, anyway?

After looking at itemptr.h, off.h, ginpostinglist.c and tidbitmap.c, it
seems that an ItemPointer is a block number from [0, 0xFFFFFFFe]; and
an offset number from [1, MaxHeapTuplesPerPage] which is by default [1,
291].

Attached is a patch that clarifies what I've found so far and gives
clear guidance to table AM authors. Before I commit this I'll make sure
that following the guidance actually works for the columnar AM.

Regards,
Jeff Davis

[1] Even for the current version of columnar, which doesn't support
indexes or updates, we implemented a hack to provide dummy TIDs because
some places expect them (see analyze.c:compare_rows()).