Re: MaxOffsetNumber for Table AMs

On Fri, Apr 30, 2021 at 10:56 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think that would be the best long-term plan. I guess I have two
> distinguishable concerns. One is that I want to be able to have
> indexes with a payload that's not just a 6-byte TID; e.g. adding a
> partition identifier to support global indexes, or replacing the
> 6-byte TID with a primary key reference to support indirect indexes.
> The other concern is to be able to have table AMs that use arbitrary
> methods to identify a tuple. For example, if somebody implemented an
> index-organized table, the "TID" would really be the primary key.
>
> Even though these are distinguishable concerns, they basically point
> in the same direction as far as index layout is concerned. The
> implications for the table AM layer are somewhat different in the two
> cases, but both argue that some places that are now talking about TIDs
> should be changed to talk about Datums or something of that sort.

I don't know how it's possible to do any of this without first
addressing what the table AM does in cases where heapam currently does
a non-HOT update. You obviously cannot have the equivalent of
duplicate TIDs when your new table AM runs into these scenarios. So
what do you do instead? How do you make your clustered index/IoT style
identifiers (i.e. your strictly logical TID-like identifiers) deal
with that case?

ISTM that this is by far the biggest issue with generalizing the table
AM for use by a tableam (that isn't already very much like heapam). I
am always surprised to be the one that has to point it out during
these discussions. It's a huge issue.

--
Peter Geoghegan