Re: MaxOffsetNumber for Table AMs

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-04-30 16:35:34 Re: MaxOffsetNumber for Table AMs
Previous Message Andres Freund 2021-04-30 15:59:53 Re: Race condition in InvalidateObsoleteReplicationSlots()