Eager data versioning seems to work well when the probability for a transaction to succeed is high because, when a transaction succeeds, we only did a little more work than was strictly necessary to update the system memory. In particular, the only overhead we incurred was (1) we had to write to an undo log and (2) we had to get rid of the undo log after the transaction committed. However, (2) doesn't really cost anything at all because we can simply overwrite the undo log when processing the next transaction. Thus, the only real overhead is (1)!

Nice observation @kevtan! Eager versioning optimises for the case when there are few conflicts as the commit step can execute very quickly while aborting requires a write to the undo log. This versioning mechanism is best for when we anticipate transactions to succeed without conflict ie touching small portions of memory or running on only a few threads.