> > 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 <http://www.postgrespro.com>
