Re: MaxOffsetNumber for Table AMs - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 36483dfed9012dac4791a0ec94dd60b295d2e596.camel@j-davis.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: MaxOffsetNumber for Table AMs
List pgsql-hackers
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()).


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Small issues with CREATE TABLE COMPRESSION
Next
From: Robert Haas
Date:
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart