Re: 64 bit transaction id

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Павел Ерёмин <shnoor111gmail(at)yandex(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 64 bit transaction id
Date: 2019-11-01 17:10:38
Message-ID: 20191101171038.6nmbvdiixnhbwe77@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 01, 2019 at 10:25:17AM +0100, Pavel Stehule wrote:
>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.
>

It certainly can be an issue for large and busy systems, that may need
anti-wraparoud vacuum every couple of days. If that requires rewriting a
couple of TB of data, it's not particularly nice. That's why 64-bit XIDs
were discussed repeatedly in the past, and it's likely to get even more
pressing as the systems get larger.

>I am not sure if increasing this range can has much more fatal problems
>(maybe later)
>

Well, not fatal, but naive approaches can increase per-tuple overhead.
And we already have plenty of that, hence there were proposals to use
page epochs and so on.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-11-01 17:10:43 Re: Resume vacuum and autovacuum from interruption and cancellation
Previous Message Tomas Vondra 2019-11-01 17:04:06 Re: On disable_cost