-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Query Integration
-
Fully Compatible
-
ALL
-
v7.0, v6.0, v5.0
-
-
QI 2023-10-16, QI 2023-10-30, QI 2023-11-13, QI 2023-11-27, QI 2023-12-11, QI 2023-12-25, QI 2024-01-08, QI 2024-01-22
-
(copied to CRM)
The bug is a result of two different optimizations not being aware of each other. Basically, this is what's going on when there are multiple $match stages and the correlated one isn't the first:
1. TS-specific optimization of predicates replaces the correlated match with a filter on a collection access stage.
2. Lookup-specific optimization that is supposed to cache results from an uncorrelated collection access fails to notice that it cannot be applied here and caches the results of the collection access with the first seen key, which are then reused with the following keys.
Combining two $match stages into one makes it sufficiently complex to disable optimization #1.
Swapping the two $match stages allows optimization #2 to realize the cache should be abandoned.