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!)