On Fri, Apr 30, 2021 at 8:06 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > My thought at the moment is that all APIs above the AM level ought > to be redefined to use uint64 for tuple identifiers. heapam and > related index AMs could map block + offset into that in some > convenient way, and other AMs could do what they like. > > 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.
I agree. It'll be easier for a new table AM to be developed with that constraint than it will be to retrofit it to every index AM. It probably wouldn't be that hard to make nbtree deduplication and GIN posting list compression work with uint64 TIDs. But variable-width TIDs are a very different matter. Compatibility with index AMs is more than a matter of switching out the tuple identifier -- if you invent something that has totally different performance characteristics for index AMs, then it's likely to break tacit assumptions about the cost of certain things. For example, index tuple deletion probably relies on the fact that there just isn't that many table blocks to visit (to get an XID for recovery conflict purposes) in practice due to various locality-related effects. Plus deduplication ameliorates problems with version churn in indexes -- presumably the same problems will exist when any new table AM is used, and so it'll be useful to address the same problems in the same way. I agree that it might well be useful to make TIDs fully logical (not "physiological" -- physical across blocks, logical within blocks) for some new table AM. Even then, it would still definitely be a good idea to make these logical TID values correlate with the physical table structure in some way. Plus TIDs should still be fixed size. If a new table AM can't do it that way then that certainly needs to be justified -- it's unreasonable to imagine that it simply isn't the table AM's problem to solve. -- Peter Geoghegan