|
This turns out to be a dup of SERVER-20768.
Because I've chased this down, I'll write up my observations (even though SERVER-20768 and the trickle of other dupes linked to that over the years basically includes all of them):
- The claim is correct, doing a range query on the exclusive upper bound of a chunk will needlessly scatter the request to an additional shard (assuming the shard for the following chunk is not already required for some other chunk covered by the range).
- I don't see any reason to believe this is a correctness problem.
- From what I can tell, the code has been this way since at least 2012.
- When generating IndexBounds, the appropriate inclusive/exclusive properties are preserved.
- When flattening the IndexBounds into a BoundList, the granularity is lost. A BoundsList is documented as inclusive on both ends.
- Unconditionally changing isMaxInclusive from true to false would be a correctness bug (this was never suggested, but figured I'd put it out there).
As far as making a change goes, I have can think of an obvious adjustment to the algorithm for preserving any exclusive upper bounds when computing the BoundList, but it's not obvious to me it's correct. I don't have any reason to believe it's wrong, but this isn't something I'd feel confident guessing at.
|