# AND_SORTED vs AND_HASH plan stages > Source-anchored research for AND_SORTED vs AND_HASH plan stages. Run status: COMPLETED. Parent: [MongoDB Compound Index Design: ESR, Selectivity, Covering and Multikey Bounds](https://llms-explorer.com/tree/mongodb-compound-index-design-esr-selectivity-covering-and-multikey-bounds/) · 4 facets · 12 facts · page: https://llms-explorer.com/tree/and-sorted-vs-and-hash-plan-stages/ ## Structure and components - AND_SORTED's “sorted” describes the RecordId order of its child streams, not the query's requested sort order. The MongoDB 6.0 manual allows intersection for some sorted queries when an index used for a predicate also supplies part of the sort; intersection does not apply when the sort needs an index wholly separate from the filter. (high confidence) — [source](https://dev.to/franckpachot/mongodb-index-intersection-and-postgresql-bitmap-scan-40a6) ## How it works - When explain shows AND_SORTED or AND_HASH in a plan, MongoDB is using index intersection. Inspect the winning plan and execution statistics to see which intersection strategy actually ran. (high confidence) — [source](https://web.archive.org/web/2024/https://www.mongodb.com/docs/v6.0/core/index-intersection/) - Index intersection is a candidate plan, not a guarantee: MongoDB can choose one IXSCAN instead. In source revision 35647d07, the plan ranker breaks ties in favor of single-index plans because intersection can examine more index keys; a compound index can constrain both predicates in one index traversal. (high confidence) — [source](https://github.com/mongodb/mongo/blob/35647d07bc4bc11966c90fe7100eb1db0b0ac1d9/src/mongo/db/query/plan_ranker.h) - AND_SORTED assumes every child produces RecordIds in sorted order. It advances child streams toward a target RecordId and emits an ID when the required children reach that same ID. (high confidence) (verified as of 2026-10-22) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/and_sorted.h) - An intersection stage appears only when the planner selects an intersection candidate. In Franck Pachot's 100,000-document example, MongoDB generated an AND_SORTED candidate but selected a single-index plan. (high confidence) — [source](https://dev.to/franckpachot/mongodb-index-intersection-and-postgresql-bitmap-scan-40a6) ## Problems, failure modes and limitations - The current classic AndHashStage defaults to a 32 MiB buffer limit and raises QueryExceededMemoryLimitNoDiskUseAllowed when buffered usage exceeds the configured limit. (low confidence) (verified as of 2026-10-22) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/and_hash.cpp) ## Facts and statements - AND_SORTED and AND_HASH both intersect RecordId sets from separate index scans. AND_SORTED advances input streams that share RecordId order and can merge them incrementally. AND_HASH builds a hash table from one child scan and probes it with the other, so it must consume the build-side scan before it can return matches. (high confidence) — [source](https://groups.google.com/g/mongodb-dev/c/j2Mp5zNU7T4) - MongoDB 6.0 documentation states hash-based intersection is disabled by default and sort-based intersection is disfavored in plan selection. Franck Pachot's article, edited 2026-03-09, also records the hash-intersection setting as false in its tested environment. Verify server version and internal settings before expecting AND_HASH. (medium confidence) (verified as of 2026-03-09) — [source](https://web.archive.org/web/2024/https://www.mongodb.com/docs/v6.0/core/index-intersection/) - MongoDB issue SERVER-14961 records an index-intersection ranking regression specific to MongoDB 2.6.4 and says the fix shipped in 2.6.5; this historical incident does not establish current-version planner behavior. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-14961) - AND_SORTED and AND_HASH implement index intersection by comparing RecordIds from their child stages and retaining matches shared across the children. (high confidence) (verified as of 2026-10-22) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/and_sorted.h) - AND_HASH builds a RecordId-keyed in-memory map from preceding children, then probes the final child. With two children, it reads the first child to completion before it can return matches from the second; this makes the stage blocking and its memory use proportional to buffered results. (high confidence) (verified as of 2026-10-22) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/and_hash.cpp) - The AND_SORTED ordering criterion applies to RecordIds. A query's requested field sort must be evaluated separately from the stage name. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/and_sorted.h)