Re: MaxOffsetNumber for Table AMs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: MaxOffsetNumber for Table AMs
Date: 2021-04-30 16:35:34
Message-ID: 3268871.1619800534@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-04-30 16:39:23 Re: pg_amcheck contrib application
Previous Message Jeff Davis 2021-04-30 16:28:08 Re: MaxOffsetNumber for Table AMs