-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.0.0-rc6
-
Component/s: Querying
-
None
-
Query Optimization
-
v4.0
-
(copied to CRM)
Due to changes made in SERVER-29839 and SERVER-32367 during 3.7 development, we now acquire locks prior to query parsing in the find command path. This is a behavior change in 4.0 compared to previous stable versions, which did not hold locks while parsing the query.
Typically, parsing is fairly fast, but we have observed performance problems such as SERVER-35693 and SERVER-30189 in which parsing was time consuming. Therefore, there is some risk of this behavior change causing performance problems on MMAPv1, where a MODE_S lock is held instead of a MODE_IS intent shared lock. Even on WiredTiger, there is some risk of this causing a performance problem---if the parsing phase can run for seconds or minutes without yielding its intent locks, then it is possible for an operation that requires a strong lock to be blocked, which in turn will block subsequent queued readers and writers waiting for intent locks.
- is related to
-
SERVER-35693 Parsing of $in takes quadratic time due to O(n^2) boost::flat_set constructor
- Closed
-
SERVER-29839 Protect against UUID->NSS mapping changing after looking it up in all commands that use parseNsOrUUID
- Closed
-
SERVER-32367 AutoGetCollectionOrView and its related classes perform shard version checking on a view
- Closed
-
SERVER-30189 Reduce calls to allocator for large $in expressions
- Closed