12.02.2026 12:18, Heikki Linnakangas wrote: > One idea is that we could first introduce the 33-bit epoch system on the > heap pages, without changing the clog and without eliminating > anti-wraparound vacuums. The immediate benefit would be that when you > freeze a page, if there are no dead tuples, you wouldn't actually need > to modify the page, and wouldn't need to dirty it. The rule would be > that if you see an XID that's older than relfrozenxid (taking the epoch > into account), you can assume that it committed and is visible to everyone. > > After that, as a follow-up patch, expand clog to 64 bits and eliminate > the need for anti-wraparound vacuums.
There is no need in 33-bit on-page epoch, imho. 32 would be enough: - given we are limited by LSN numbers, 64bit transaction is unreachable. We could safely assume transaction is 63bit - and transaction's difference on the page couldn't be larger 2^31. Even current patchset for 64bit transaction contains this artificial limitation, although it is used only to make more checks about correctness, and theoretically could be lifted away. - then on-page epoch could be 32bit: 31bit difference + 32bit base = 63bit transaction. In this scenario, base will contain bits from 31 to 62 of transaction, and xmin-xmax could be a) either signed addition to base (therefore could be negative) ie in range -2^31..2^31-1, b) or be in positive range 0..2^32-1. In both cases difference between minimum and maximum have to be lesser than 2^31. Case b is simpler to implement since we still need in representation of InvalidTransactionId, BootstrapTransactionId and FrozenTransactionId. (btw, why we still need separate BootstrapTransactionId and FrozenTransactionId? It just because of pg_upgrade? Pitty. Completely useless difference.) 12.02.2026 12:18, Heikki Linnakangas wrote: > - It *will* increase the size of the database. That alone makes it a > non-starter. I suppose it is about "64bit xid in on-disk touple". Size issue could be solved in alternative way: page compression. There are already two existing and used in production implementations: one our in-house proprietary we sell in our product, other were discussed in this maillist couple of years ago and happily adopted by one of our competitor. Our customers are glad to use compression since it both reduces disk space usage and increases query performance. Although we have some issues with integrating it with AIO. But they are solvable. High bits of 64-bit xids in one page are mostly equal and will be compressed really well. Yes, they still will consume memory of shared buffers. And it is bigger issue imho. -- regards Yura Sokolov aka funny-falcon
