The proposed option is not much different from what it is now.
We are not trying to save some space - we will reuse the existing one. We just work in 64 bit transaction counters. Correct me if I'm wrong - the address of the next version of the line is stored in the 6 byte field t_cid in the tuple header - which is not attached to the current page in any way - and can be stored anywhere in the table. Nothing changes.
I often explain things very poorly, but I will try.
for example
Each transaction is assigned a unique 64-bit xid.
In the tuple header, we replace 32-bit xmin and xmax - with one 64-bit field - let's call it xid.
Suppose
Transaction 1 does INSERT
The first version is created (Tuple1).
Tuple1. Tuple_header.xid = Transacrion1.xid and Tuple1. Tuple_header. t_cid = 0;
Transaction 3 (started after transaction 1) does UPDATE
The second version is created (Tuple2).
Tuple1. Tuple_header. t_cid = (address) Tuple2;
Tuple2. Tuple_header.xid = Transacrion3.xid and Tuple2. Tuple_header. t_cid = 0;
Transaction 2 (started between transaction1 and transaction2) makes SELECT
Reads Tuple1. Transaction 2 sees that Tuple1.Tuple_header.xid <Transacrion2.xid, sees that the address Tuple1 is filled. Tuple_header. t_cid, follow it and read the version of Tuple2.
02.11.2019, 21:15, "Tomas Vondra" <tomas.von...@2ndquadrant.com>:
On Sat, Nov 02, 2019 at 07:07:17PM +0300, Павел Ерёмин wrote:
The proposed option does not need to change the length of either the page
header or tuple header. Therefore, you will not need to physically change
the data.
--
So how do you link the tuple versions together? Clearly, that has to be
stored somewhere ...
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services