On Mon, May 3, 2021 at 10:57 AM Jeff Davis <pgsql@j-davis.com> wrote:
> For the purposes of this discussion, what's making my life difficult is
> that we don't have a good definition for TID, leaving me with two
> options:
>
> 1. be overly conservative, accept MaxOffsetNumber=2048, wasting a
> bunch of address space; or
tidbitmap.c uses MaxHeapTuplesPerPage as its MAX_TUPLES_PER_PAGE,
which is much lower than MaxOffsetNumber (it's almost 10x lower). I
wonder what that means for your design.
> 2. risk the mapping between TID and row number could break at any
> time
Though this clearly is the immediate problem for you, I think that the
real problem is that the table AM kind of tacitly assumes that there
is a universality to item pointer TIDs -- which is obviously not true.
It might be useful for you to know what assumptions index AMs can make
about how TIDs work in general, but I think that you really need an
index-AM level infrastructure that advertises the capabilities of each
index AM with respect to handling each possible variation (I suppose
you have heapam, 6 byte uint, and maybe 8 byte uint).
The easiest reasonable short term design for you is probably to find a
way to make 6 byte TIDs into 48-bit unsigned integers (perhaps only
conceptually), at least in contexts where the columnar table AM is
used. You'll still need the index AM for that. This at least makes
64-bit TID-like identifiers a relatively simple conceptually shift.
--
Peter Geoghegan