In WT-3854 we changed how wt_txn_set_commit_timestamp walks the queue. It used to walk backward to find its place in the list and that likely minimized the walking since the queue is in timestamp order and we're likely inserting timestamps that are increasing generally.
Now, we walk forward, cleaning up earlier transactions that can be removed. We do stop when we find our timestamp slot. But we could be walking many more entries.
Although we have a statistic for empty and inserting at the end, we should add a statistics to know how many entries we walk per call and try to measure if there is any performance impact when the queues get very large. (Initial measurements of just WT showed 12% improvement by avoiding taking the write lock and small MongoDB tests showed no change.)
- causes
-
WT-5440 __wt_txn_clear_read_timestamp() has an unnecessary serialization point
- Closed
- is depended on by
-
SERVER-35958 Big CPU load increase (×4) on secondary by upgrading 3.4.15 → 3.6.5
- Closed
- related to
-
WT-4213 Rename lock statistics that have redundant or misleading text
- Closed