Re: MaxOffsetNumber for Table AMs

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Apr 30, 2021 at 11:06 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andres seems to feel that we should try to allow variable-width
>> tupleids, but I'm afraid that the cost/benefit ratio for that
>> would be pretty poor.

> There are two major reasons why I want variable-width tuple IDs. One
> is global indexes, where you need as many bits as the AMs implementing
> the partitions need, plus some extra bits to identify which partition
> is relevant for a particular tuple. No fixed number of bits that you
> make available can ever be sufficient here,

I agree that global indexes need more bits, but it doesn't necessarily
follow that we must have variable-width TIDs. We could for example
say that "real" TIDs are only 48 bits and index AMs that want to be
usable as global indexes must be capable of handling 64-bit TIDs,
leaving 16 bits for partition ID. A more forward-looking definition
would require global index AMs to store 96 bits (partition OID plus
64-bit TID). Either way would be far simpler for every moving part
involved than going over to full varlena TIDs.

> Another problem in this general area is that there is quite a bit of
> code that thinks a TID is specifically a block number and an offset,
> like the Bitmap Index/Heap Scan code, for example. But making tuple
> IDs wider doesn't help with that problem either.

Agreed, that's an area that will need a lot of thought for anything that
we do here. But varlena TIDs surely do not make that easier to fix.

> What problem do you think this proposal does solve?

Accommodating table AMs that want more than 48 bits for a TID.
We're already starting to run up against the fact that that's not
enough bits for plausible use-cases. 64 bits may someday in the far
future not be enough either, but I think that's a very long way off.

regards, tom lane