Re: 64 bit TID? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: 64 bit TID?
Date
Msg-id CAH2-WzmUE2_6fL=Ci=kFQY6F=Ej9m2QgkzPywEJHxBySYVWfZg@mail.gmail.com
Whole thread Raw
In response to Re: 64 bit TID?  (Chris Cleveland <ccleveland@dieselpoint.com>)
Responses Re: 64 bit TID?
List pgsql-hackers
On Mon, Sep 13, 2021 at 3:30 PM Chris Cleveland
<ccleveland@dieselpoint.com> wrote:
> Wow, thank you, that is some thread. It discusses the issues
> thoroughly.

If somebody wants to make TIDs (or some generalized TID-like thing
that tableam knows about) into logical identifiers, then they must
also answer the question: identifiers of what?

TIDs from Postgres heapam identify a physical version, or perhaps a
HOT chain -- which is not how TIDs work in other DB systems that use a
heap structure. This is the only reason why we can mostly think of
indexes as data structures that don't need to be involved in
concurrency control. Postgres index access methods don't usually need
to know anything about locks that protect the logical structure of the
database.

The option of just creating a new distinct TID (for the same logical
row) buys us the ability to keep index access methods rather separate
from everything else -- which helps with extensibility. No logical
locks are required in Postgres. Complicated designs that bleed into
other parts of the system (designs like ARIES/KVL and ARIES/IM) are
unnecessary.

> Questions:
>
> Would widening the existing ItemPointer to 64 bits now preclude a
> variable-length TID in the future? Or make it more difficult?
>
> How much work would it take?

If it was just a matter of changing the data structure then I think it
would be far easier.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Estimating HugePages Requirements?
Next
From: Michael Paquier
Date:
Subject: Re: Multiple hosts in connection string failed to failover in non-hot standby mode