On Mon, 13 Sept 2021 at 17:50, Chris Cleveland <cclevel...@dieselpoint.com> wrote: > > All, > > I'm considering a new design for a specialized table am. It would simplify > the design if TIDs grew forever and I didn't have to implement TID reuse > logic.
TID reuse logic also helps clean up index tuples for deleted table tuples. I would suggest to implement TID reuse logic if only to prevent indexes from growing indefinately (or TID limits reached, whichever first). > The current 48 bit TID is big, but I can see extreme situations where it > might not be quite big enough. If every row that gets updated needs a TID, > and something like an IoT app is updating huge numbers of rows per second > using multiple connections in parallel, there might be a problem. If your table contains such large amounts of (versions of) tuples, you might want to partition your table(s), as that allows the system to move some bits of tuple identification to the the relation identifier. > This is especially true if each connection requests a batch of TIDs and then > doesn't use all of them. For the HeapAM this is never the case; TIDs cannot be allocated without use (albeit some may be used for rolled-back and thus dead tuples). > 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. Kind regards, Matthias van de Meent [0] https://www.postgresql.org/message-id/flat/0bbeb784050503036344e1f08513f13b2083244b.camel%40j-davis.com
