Wildcard index query-planner behavior and explain rejectedPlans
Parent: MongoDB Wildcard and Hidden Indexes, Index Builds and Index Overhead · Published reference · snapshot 2026-10-21 · skill ranked-1cb7f7b2
↓ Facts as markdownall context files
Source-anchored research for Wildcard index query-planner behavior and explain rejectedPlans. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Starting in MongoDB 8.0, rejectedPlans for an aggregation explain contain only the find portion used for plan selection; later pipeline stages such as $group are omitted from those rejected plan trees. (low confidence) (verified as of 2026-10-21) [source]
How it works
- Compound wildcard indexes have existed since MongoDB 7.0. Their wildcard term can support one query predicate while regular terms can support remaining predicates. Percona's 2019 MongoDB 4.2 slides say wildcard indexes could not be compounded, so that older restriction is version-specific. (high confidence) (verified as of 2026-10-21) [source]
- queryPlanner.rejectedPlans is the array of candidate plans considered and rejected by the optimizer. MongoDB says the array can be empty when no other candidate exists, and rejected plan entries have the same fields as winningPlan. (high confidence) (verified as of 2026-10-21) [source]
- MongoDB defines queryPlanner.rejectedPlans as candidate plans considered and rejected; the array can be empty when there was no other candidate. Explain generates candidates without consulting the plan cache and does not cache its winner. Read the array as the alternatives considered by that explain run, not as an exhaustive list of every possible plan or proof of which cached plan a normal execution used. (high confidence) (verified as of 2026-10-21) [source]
- In allPlansExecution mode, MongoDB reports execution information captured during plan selection for candidate plans; executionStats runs the selected winning plan to completion. Starting in MongoDB 8.3, multi-planning with a cost-based-ranker backup is the default selection mechanism for eligible queries. Treat candidate statistics and ranking fields as version-dependent, and inspect cost estimates where the output includes them. (high confidence) (verified as of 2026-10-21) [source]
Problems, failure modes and limitations
- MongoDB may use the same wildcard index to support each independent argument of a $or or aggregation $or operator. The one-predicate limit is scoped to multiple predicates in a conjunction. (low confidence) (verified as of 2026-10-21) [source]
- An empty rejectedPlans array does not mean a wildcard index was used. MongoDB says wildcard indexes cannot support queries for missing fields; a community example shows a COLLSCAN with rejectedPlans: [] for an $exists: false query. (high confidence) (verified as of 2026-10-21) [source]
Comparisons and alternatives
- queryPlanner reports the selected plan without executing the query. executionStats runs the winning plan to completion. allPlansExecution also returns trial-period statistics for other candidate plans, rather than full-run statistics for each rejected plan. (high confidence) (verified as of 2026-10-14) [source]
- explain ignores plan-cache entries, generates candidate plans for that explain run, chooses a winner, and does not cache that winner. An ordinary query may use a cached plan, so its runtime plan can differ from the explain winner. (high confidence) (verified as of 2026-10-21) [source]
- MongoDB issue SERVER-102192 documents a compound wildcard explain case where an IXSCAN is followed by FETCH with an $exists:true filter still applied. The ticket notes that wildcard-term placement can expose a compound wildcard bounds limitation, so inspect residual FETCH filters alongside index bounds instead of assuming the wildcard scan enforced every predicate. (medium confidence) [source]
Facts and statements
- For a multi-field conjunction, one wildcard index term can supply index bounds for only one query predicate; MongoDB selects that predicate from relevant wildcard paths. A 2023 community explain example shows the wildcard IXSCAN on path A while predicate C remains in FETCH.filter. (high confidence) (verified as of 2026-10-21) [source]
- MongoDB issue SERVER-96805 reports that repeated runs of one wildcard query in a replica_sets_jscore_pqs_fallback reproduction produced different candidate plans and rejectedPlans. The issue was closed Won't Do on 2025-04-23. Treat this as one scoped reproduction; the ticket does not establish that wildcard explain output is generally nondeterministic. (low confidence) (verified as of 2025-04-23) [source]
- For MongoDB Server, one wildcard index term can support only one query-field predicate in a plan. In a compound wildcard index, non-wildcard terms can support additional query fields. MongoDB may reuse the same wildcard index for independent $or branches, and its manual says unsupported predicates appear in explain.queryPlanner.rejectedPlans. (high confidence) (verified as of 2026-10-21) [source]
- MongoDB Server's one-predicate-per-wildcard-term rule does not apply to every MongoDB-compatible service. Microsoft's Azure Cosmos DB for MongoDB documentation says that its wildcard indexes can support multiple fields in query predicates, so keep this planner rule scoped to MongoDB Server. (high confidence) (verified as of 2026-04-27) [source]
Children
- No children recorded.