On Fri, Apr 30, 2021 at 11: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.
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. 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. What problem do you think this proposal does solve? -- Robert Haas EDB: http://www.enterprisedb.com
