Re: 64 bit transaction id - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: 64 bit transaction id
Date
Msg-id CA+hUKG+MPjUhk74KiaZcR7t1JEPVoe3A0F8uknenTqaXZ0JAww@mail.gmail.com
Whole thread Raw
In response to Re: 64 bit transaction id  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Sat, Nov 2, 2019 at 6:15 AM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> 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?).

There have been so many discussions of this topic that it's hard to search for.

Since we have in fact begun to take some baby steps towards using 64
bit transaction IDs in a few places, I decided to create a new wiki
page to try to keep track of the various discussions.  If you know
where to find the 'best' discussions (for example the one where, if I
recall correctly, it was Heikki who proposed a 'reference'
FullTranasctionId on the page header) and any proposals that came with
patches, then I'd be grateful if you could add links to it to this
wiki page!

https://wiki.postgresql.org/wiki/FullTransactionId



pgsql-hackers by date:

Previous
From: Andrzej Barszcz
Date:
Subject: function calls optimization
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Include triggers in EXPLAIN