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

From Jeff Davis
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 50948761ea906849915e299950a1b42ca30c7d6d.camel@j-davis.com
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: MaxOffsetNumber for Table AMs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2021-04-30 at 11:06 -0400, Tom Lane wrote:
> My thought at the moment is that all APIs above the AM level ought
> to be redefined to use uint64 for tuple identifiers.

One challenge might be reliance on InvalidOffsetNumber as a special
value in a number of places (e.g. bitmap index scans). That doesn't
seem like a major problem though.

> heapam and
> related index AMs could map block + offset into that in some
> convenient way, and other AMs could do what they like.

Do you mean that indexes would be expected to hold a uint64, a 48-bit
int (that directly maps to a uint64), or still hold an ItemPointerData?

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Race condition in InvalidateObsoleteReplicationSlots()
Next
From: Tom Lane
Date:
Subject: Re: MaxOffsetNumber for Table AMs