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

From Tom Lane
Subject Re: MaxOffsetNumber for Table AMs
Date
Msg-id 3268871.1619800534@sss.pgh.pa.us
Whole thread Raw
In response to Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: MaxOffsetNumber for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> 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.

> 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?

ISTM that would be up to the index AM.  We'd need some interlocks on
which index AMs could be used with which table AMs in any case, I think.

It'd likely not be hard for existing index AMs to be repurposed to store
"any 48-bit TID", but extending them to full 64-bit TIDs may be
impractical.

I think the hard part may really be in places like tidbitmap.c, which
one would wish to be AM-independent, but right now it's quite specific
to heap-style TIDs.  Maybe we can think of a way to parameterize it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: MaxOffsetNumber for Table AMs
Next
From: Robert Haas
Date:
Subject: Re: pg_amcheck contrib application