On Fri, Nov 01, 2019 at 12:05:12PM +0300, Павел Ерёмин wrote:
> 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.
>
I think that assumes we can easily identify the next version of a tuple,
and I don't think we can do that. We may be able to do that for for HOT
chains, but that only works when the next version fits onto the same
page (and does not update indexed columns). But when we store the new
version on a separate page, we don't have any link between those tuples.
And adding it may easily mean more overhead than the 8B we'd save by
only storing a single XID.
IMO the most promising solution to this is the "page epoch" approach
discussed some time ago (1-2 years?).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
