This ticket follows the work done in WT-7106. A new variable WT_MAX_CONSECUTIVE_REVERSE_MODIFY has been defined to limit the number of consecutive reverse modifies during reconciliation before performing a full update.

Instead of having a hardcoded value, we could have a dynamic approach. Find below a few ideas from the WT-7106 discussion:

• If a reverse delta uses 1% of the space a full record would, then we might store 100 reverse deltas per full update. If a reverse delta uses 50% or more of the space, we might store 10.

• Store a reverse modify if it will save at least N bytes (or N% of the record size) where N increases with the number of consecutive reverse modifies we've stored.

• This limit could also be based on per-table data instead of database wide.