-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Query Planning, Sharding
-
None
-
Fully Compatible
-
v6.1, v6.0
-
QO 2022-05-02, QO 2022-05-16, QE 2022-05-30, QE 2022-06-27, Sharding EMEA 2022-07-25, Sharding EMEA 2022-08-08, Sharding EMEA 2022-08-22, Sharding EMEA 2022-09-05, Sharding EMEA 2022-09-19, Sharding EMEA 2022-10-03, Sharding EMEA 2022-10-17, Sharding EMEA 2022-10-31, Sharding EMEA 2022-11-14
In SERVER-65085, we are planning to add the shard version epoch and timestamp to the SBE plan cache key. This is necessary to make sure that an SBE plan cache entry cannot be re-used across a refineCollectionShardKey boundary.
This ticket will improve the solution from SERVER-65085 by adding logic to clean up SBE plan cache entries associated with the older epoch when the collection's epoch is incremented. We could just leave the invalid cache entries around in the cache, since the changes to the plan cache key will prevent these old cache entries from being reused. Eventually they would be deleted due to the plan cache's LRU replacement policy. As an improvement, however, we should clean up the stale cache entries more promptly in order to avoid using memory unnecessarily.
The exact implementation strategy for doing this plan cache invalidation still needs to be decided in consultation with max.hirschhorn@mongodb.com, kaloian.manassiev@mongodb.com, and tommaso.tocci@mongodb.com.
- is related to
-
SERVER-65085 SBE plan cache entries can be incorrectly reused after a refineCollectionShardKey operation
- Closed
-
SERVER-73395 Query on temporary resharding collection has plan cache entry after resharding completes
- Backlog