Re: 64-bit XIDs again

On Thu, Jul 30, 2015 at 5:31 PM, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz
> wrote:

> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In the other hand PG tuple overhead is already the largest among the
alternatives.
Even if storage keeps getting faster and cheaper stuff you can't ignore the
overhead of adding yet another 8bytes to each tuple.