Re: 64 bit transaction id

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Павел Ерёмин <shnoor111gmail(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 64 bit transaction id
Date: 2019-11-03 21:41:54
Message-ID: CA+hUKG+MPjUhk74KiaZcR7t1JEPVoe3A0F8uknenTqaXZ0JAww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 2, 2019 at 6:15 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-11-03 21:49:36 Re: [PATCH] Include triggers in EXPLAIN
Previous Message Andrzej Barszcz 2019-11-03 20:56:31 function calls optimization