Priority: Major - P3
Affects Version/s: None
Fix Version/s: 5.1 Required
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
- 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.