> > 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
