On Thu, Jul 30, 2015 at 5:24 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 07/30/2015 04:26 PM, Alexander Korotkov wrote:
Also, I think it's possible to migrate to 64-bit XIDs without breaking pg_upgrade. Old tuples can be leaved with 32-bit XIDs while new tuples would be created with 64-bit XIDs. We can use free bits in t_infomask2 to distinguish old and new formats.
I think we should move to 64-bit XIDs in in-memory structs snapshots, proc array etc. And expand clog to handle 64-bit XIDs. But keep the xmin/xmax fields on heap pages at 32-bits, and add an epoch-like field to the page header so that logically the xmin/xmax fields on the page are 64 bits wide, but physically stored in 32 bits. That's possible as long as no two XIDs on the same page are more than 2^31 XIDs apart. So you still need to freeze old tuples on the page when that's about to happen, but it would make it possible to have more than 2^32 XID transactions in the clog. You'd never be forced to do anti-wraparound vacuums, you could just let the clog grow arbitrarily large.
Nice idea. Storing extra epoch would be extra 4 bytes per heap tuple instead of extra 8 bytes per tuple if storing 64 bits xmin/xmax.
But if first column is aligned to 8 bytes (i.e. bigserial) would we loose this 4 bytes win for alignment?
There is a big downside to expanding xmin/xmax to 64 bits: it takes space. More space means more memory needed for caching, more memory bandwidth, more I/O, etc.
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company