On Fri, 2021-04-30 at 12:51 -0400, Robert Haas wrote:
> 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, because a global index
> always needs to have extra bits compared to a partition-local index;
> if you let the partition-local index use more bits, the global index
> now needs even more space. The other is indirect indexes, work Álvaro
> proposed a few years ago, where the index entry points to the primary
> key value rather than a TID. The space needs for that are based on
> the
> type of the primary key column. This proposal solves neither of those
> problems.
The particular problem I have now is that Table AMs seem to support
indexes just fine, but TIDs are under-specified so I don't know what I
really have to work with. BlockNumber seems well-specified as
0..0XFFFFFFFE (inclusive), but I don't know what the valid range of
OffsetNumber is for the purposes of a TableAM.
Part of changing to uint64 would be specifying the TIDs in a way that I
could rely on in the future.
The problems you mention above are above the table AM layer, so they
seem orthogonal. There would still need to be an ID that table AMs can
use to fetch a tuple from a particular physical table.
In the future we may support primary unique indexes at the table AM
layer, which would get more interesting. I can see an argument for a
TID being an arbitrary datum in that case, but I haven't really
considered the design implications. Is this what you are suggesting?
Regards,
Jeff Davis
