Re: Add 64-bit XIDs into PostgreSQL 15 - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id CALT9ZEHvtJ1a7OzFydyHRz631e_40+w+ad7iu9N21Rey80W1cw@mail.gmail.com
Whole thread Raw
In response to Re: Add 64-bit XIDs into PostgreSQL 15  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
Did you consider using 4 bytes for pd_xid_base and another 4 bytes for
(pd_xid_base/pd_multi_base)? This would allow calculating XMIN/XMAX
as:

XMIN = (t_min_extra_bits << 32) | t_xmin
XMAX = (t_max_extra_bits << 32) | t_xmax

... and save 8 extra bytes in the pd_special area. Or maybe I'm
missing some context here?
Hi, Alexander!

In current design it is not possible, as pd_xid_base is roughly just a minimum 64-xid of all tuples that may fit this page. So we do not make any extra guess that it should be in multiples of 2^32.

If we make pd_xid_base in multiples of 2^32 then after current XID crosses the border of 2^32 then pages that contains tuples with XMIN/XMAX before this point are not suitable for tuple inserts anymore. In effect we will then have "sets" of the pages for each 2^32 "epoch" with freed space that can not be used anymore.

I think it's too big a loss for gain of just 8 bytes per page.

Thank you for your dive into this matter!

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: warn if GUC set to an invalid shared library
Next
From: Andrew Dunstan
Date:
Subject: Re: A test for replay of regression tests