For the reference, MDEV-12026 and MDEV-18644 (which implemented a fairly minor refinement to the existing InnoDB file format) were logged as 33 working days. I do not know who came up with the estimate of 5 days, but I think that it is completely unrealistic. As far as I can understand, this would involve designing not only a new index page format but also changes to the undo logging, to support that.

Designing and implementing a completely new index page format for InnoDB would be a multi-month effort. If we go down that route, I would consider implementing a completely new B-tree storage engine, including features like the following:

• Similar to MDEV-17598, have per-record transaction identifiers in secondary indexes.
• Similar to RocksDB, store every visible record version in the clustered index (essentially, include DB_TRX_ID in the PRIMARY KEY). And implement some nice page format that allows column values to be shared between records, to minimize the overhead of updating a single column.

These changes would greatly simplify MVCC and checks for implicit locks. The undo log would only be consulted for rollback and purge. For that to work, it would have to record (table_id,primary_key) for every transaction.

I have also been thinking about writing undo log records in the same stream with redo log (which depends on MDEV-12353 and MDEV-14425). We would use memory-mapped files to persistent memory. But, it looks like the RocksDB-like change (including DB_TRX_ID in the PRIMARY KEY) would greatly reduce accesses to the undo log, and we might as well keep separate undo log pages, to avoid introducing a hardware dependency, and avoid introducing constraints for redo log checkpoints.