On 07/30/2015 07:24 AM, Heikki Linnakangas wrote: > > 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
When I introduced the same idea a few years back, having the clog get arbitrarily large was cited as a major issue. I was under the impression that clog size had some major performance impacts. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
