> > Are there any plans in the works to widen the TID? > > This was recently discussed here [0] as well, but to the best of my > knowledge no material proposal to update the APIs has been suggested > as of yet. > > [0] > https://www.postgresql.org/message-id/flat/0bbeb784050503036344e1f08513f13b2083244b.camel%40j-davis.com
Wow, thank you, that is some thread. It discusses the issues thoroughly. As I see it, there are three options: 1. Make it possible to use the unused 5 bits in the existing TID scheme. The advantages: we get the full 48 bits, and it may not take a lot of work, and it makes Jeff Davis' work with Columnar easier. 2. Go to a flat 64-bit logical TID. The advantages: certain types of table AMs work better, including Columnar and LSM tree-based AMs (which I'm currently working on). 3. Go to a variable-length TID. The advantages: you can stuff any kind of payload into the TID, which would make clustered tables and certain fancy indexes easier, but would be far more work. I would contribute patches myself, but I'm not *yet* skilled enough in the ways of Postgres to do so. Questions: Would widening the existing ItemPointer to 64 bits now preclude a variable-length TID in the future? Or make it more difficult? How much work would it take? Since the thread ended in May, has the group reached any kind of consensus on the issue? -- Chris Cleveland 312-339-2677 mobile
