On Mon, Nov 27, 2017 at 11:56 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov > <a.korot...@postgrespro.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
