Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On Mon, Nov 27, 2017 at 11:56 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>> pg_prune_xid makes sense only for heap pages. Once we introduce special
>> area for heap pages, we can move pg_prune_xid there and save some bytes in
>> index pages. However, this is an optimization not directly related to
>> 64-bit xids. Idea is that if we anyway change page format, why don't apply
>> this optimization as well? But if we have any doubts in this, it can be
>> removed with no problem.
>
> My first reaction is that changing the page format seems like a
> non-starter, because it would break pg_upgrade. If we get the heap
> storage API working, then we could have a heap AM that works as it
> does today and a newheap AM with such changes, but I have a bit of a
> hard time imagining a patch that causes a hard compatibility break
> ever being accepted.

I actually think that we could use that field in indexes for storing
an epoch. This could be used to avoid having to worry about
anti-wraparound VACUUM for deleted index pages that contain a cached
XID -- the one we compare to RecentGlobalXmin as part of the recycling
interlock. (I suggested this to Sawada-san at one point, in the
context of avoiding vacuuming indexes on large append-mostly tables.)

In any case, we'd hardly go to all that effort to save just 4 bytes in
the page header.

--
Peter Geoghegan