Re: Add 64-bit XIDs into PostgreSQL 15
| От | Pavel Borisov |
|---|---|
| Тема | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Дата | |
| Msg-id | CALT9ZEHvtJ1a7OzFydyHRz631e_40+w+ad7iu9N21Rey80W1cw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add 64-bit XIDs into PostgreSQL 15 (Aleksander Alekseev <aleksander@timescale.com>) |
| Список | 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!
В списке pgsql-hackers по дате отправления: