-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
None
-
None
-
None
-
None
-
None
-
None
-
None
https://jira.mongodb.org/browse/SERVER-116135 enabled SBE to use sparse foreign indexes in $lookup via the dynamic indexed loop join (DILJ), and the current wildcard-index work enables single-path wildcard indexes while explicitly keeping compound wildcard indexes classic-only as a follow-up.
This follow-up should investigate support for compound wildcard indexes that cover the foreign field. The main correctness question is whether compound wildcard indexes are safe to use even though, unlike single-path wildcard indexes, they may still emit an index entry with a placeholder value when the wildcard field is missing rather than omitting the document entirely.
The main performance question depends on wildcard position. For a trailing wildcard such as {{{}
{a: 1, "$**": 1}{}}}, the leading field is unconstrained, so a seek degenerates into a full index scan per local key and could be a regression. For a leading wildcard such as {{{}
{"$**": 1, b: 1}{}}}, the seek may still be genuinely selective and therefore worth supporting in SBE.
The investigation should cover making eligible compound wildcard indexes available for SBE pushdown, determining which shapes must still route through DILJ versus remain classic-only, validating whether expandWildcardIndexEntry handles non-leading wildcard fields cleanly, and adding test coverage for leading and non-leading compound wildcard cases.
Related: https://jira.mongodb.org/browse/SERVER-116135 (sparse indexes in SBE $lookup), https://jira.mongodb.org/browse/SERVER-64082 (original classic-only gate for wildcard indexes in SBE $lookup).
- is related to
-
SERVER-64082 Consider usage of wildcard index for $lookup in SBE
-
- Closed
-
-
SERVER-116135 Use sparse indexes in SBE lookup
-
- Closed
-