On Mon, May 3, 2021 at 10:57 AM Jeff Davis <pg...@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
