Hi pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин <shnoor111gm...@yandex.ru> napsal:
> Hi. > sorry for my English. > I want to once again open the topic of 64 bit transaction id. I did not > manage to find in the archive of the option that I want to discuss, so I > write. If I searched poorly, then please forgive me. > The idea is not very original and probably has already been considered, > again I repeat - I did not find it. Therefore, please do not scold me > severely. > In discussions of 64-bit transaction id, I did not find mention of an > algorithm for storing them, as it was done, for example, in MS SQL Server. > What if instead of 2 fields (xmin and xmax) with a total length of 64 bits > - use 1 field (let's call it xid) with a length of 64 bits in tuple header? > In this field store the xid of the transaction that created the version. In > this case, the new transaction in order to understand whether the read > version is suitable for it or not, will have to read the next version as > well. Those. The downside of such decision is of course an increase in I / > O. Transactions will have to read the +1 version. On the plus side, the > title of the tuple remains the same length. > is 32 bit tid really problem? Why you need to know state of last 2^31 transactions? Is not problem in too low usage (or maybe too high overhead) of VACUUM FREEZE. I am not sure if increasing this range can has much more fatal problems (maybe later) Pavel > > regards, Eremin Pavel. >
