Re: 64 bit transaction id

Hi

pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин <shnoor111gmail(at)yandex(dot)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.
>