Re: 64-bit XIDs again

On 31/07/15 02:24, Heikki Linnakangas 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.

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.

- Heikki

I think having a special case to save 32 bits per tuple would cause unnecessary complications, and the savings are minimal compared to the size of current modern storage devices and the typical memory used in serious database servers.

I think it is too much pain for very little gain, especially when looking into the future growth in storage capacity andbandwidth.

The early mainframes used a base displacement technique to keep the size of addresses down in instructions: 16 bit addresses, comprising 4 bits for a base register and 12 bits for the displacement (hence the use of 4KB pages sizes now!).  Necessary at the time when mainframes were often less than 128 KB!  Now it would ludicrous to do that for modern servers!


Cheers,
Gavin

(Who is ancient enough, to have programmed such MainFrames!)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers