-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Summary
On each cached-acquisition hit, performLookup() calls checkPlacementVersionForOperation (checkShardVersionOrThrow/checkDbVersionOrThrow) to revalidate the cached acquisition against the live CollectionShardingState/DatabaseShardingState – once per document. Amortize it to once per getMore batch.
Optimization
Assume the version is stable for the getMore batch (a mid-batch placement change is low-probability); enrich all documents optimistically against the cached acquisition's captured filter, and run the placement check once before the batch is returned to the client.
Correctness
Nothing is sent until the checkpoint, so on StaleConfig at end-of-batch we discard and re-enrich via the fallback. No document validated against a stale version is ever returned.
Open questions
- Checkpoint placement (end-of-batch, pre-return).
- Redo granularity: whole batch vs an every-K-documents window to cap redo cost.
- The load-bearing assumption that mid-batch migrations are rare (frequent staleness -> batch-redo thrash).
Savings
N-1 placement checks per N-document batch. Relates to M5 (SBE / batching).