-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
Repl 2017-09-11, Repl 2017-10-02
-
0
Currently the function ReplicationCoordinatorImpl::_calculateStableTimestamp uses std::find_if to search through the list of stable timestamp candidates. The list of stable timestamp candidates is maintained in sorted order, since it is a std::set, however, std::find_if doesn't take advantage of this. Thus, it's performance is linear in the size of the candidates list, and becomes the slowest part of the set stableTimestampForStorage operation if the candidate list grows to some non-trivial size.
We can optimize this by using the std::set::upper_bound function to calculate the stable timestamp. For a std::set container, upper_bound has logarithmic complexity, and returns the first element in a sorted range that is greater than some given value. If we do something like
candidates.upper_bound(commitPoint)
we can obtain an iterator to the smallest candidate timestamp that is greater than the commit point. By decrementing this iterator by 1, we can then obtain the greatest timestamp candidate that is less than or equal to the commit point. (This is the basic concept; there are a few edge cases to handle).
This should be done to address the performance regressions introduced by SERVER-29891.
- is related to
-
SERVER-29891 Roll Back to Checkpoint: Call setStableTimestamp() when commit point or last applied changes
- Closed
-
SERVER-30845 Avoid updating the stable timestamp in WiredTiger unnecessarily
- Closed