On Mon, 13 Sept 2021 at 17:50, Chris Cleveland
<ccleveland@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'thave 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
thatgets updated needs a TID, and something like an IoT app is updating huge numbers of rows per second using multiple
connectionsin 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