| From: | Chris Cleveland <ccleveland(at)dieselpoint(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | 64 bit TID? |
| Date: | 2021-09-13 15:49:48 |
| Message-ID: | CABSN6VdevsZayUcEV_RaQ6SMjDuSvKRiKAQjYCaskL9z+wFxng@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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. This is
especially true if each connection requests a batch of TIDs and then
doesn't use all of them.
Are there any plans in the works to widen the TID?
I saw some notes on this in the Zedstore project, but there hasn't been
much activity in that project for almost a year.
Chris
--
Chris Cleveland
312-339-2677 mobile
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-09-13 15:49:49 | Re: Estimating HugePages Requirements? |
| Previous Message | Masahiko Sawada | 2021-09-13 15:43:09 | Re: Skipping logical replication transactions on subscriber side |