@@ -570,23 +570,39 @@ the collection changes to ensure optimal query plans.
570
570
571
571
To create a new query plan, the query optimizer:
572
572
573
- 1. runs the query against several indexes in parallel.
573
+ 1. runs the query against several candidate indexes in parallel.
574
574
575
- #. records the matches in a single common buffer, as though the
576
- results all came from the same index.
575
+ #. The query optimizer records the matches in a common results buffer
576
+ or buffers:
577
+
578
+ - If the candidate plans include only :term:`ordered query plans
579
+ <ordered query plan>`, there is a single common results buffer.
580
+
581
+ - If the candidate plans include only :term:`unordered query plans
582
+ <unordered query plan>`, there is a single common results buffer.
583
+
584
+ - If the candidate plans include *both* :term:`ordered query plans
585
+ <ordered query plan>` and the :term:`unordered query plans
586
+ <unordered query plan>`, there are two common results buffers, one
587
+ for the ordered plans and the other for the unordered plans.
577
588
578
589
If an index returns a result already returned by another index, the
579
- optimizer skips the duplicate match.
590
+ optimizer skips the duplicate match. In the case of the two buffers,
591
+ both buffers are de-duped.
592
+
593
+ #. stops the testing of candidate plans and selects an index when one of
594
+ the following events occur:
595
+
596
+ - An :term:`unordered query plan` has returned all the matching results; *or*
597
+
598
+ - An :term:`ordered query plan` has returned all the matching results; *or*
580
599
581
- #. selects an index when either of the following occur :
600
+ - An :term:`ordered query plan` has returned a threshold number of matching results :
582
601
583
- - The optimizer exhausts an index, which means that the index has
584
- provided the full result set. At this point, the optimizer stops
585
- querying.
602
+ - Version 2.0: Threshold is the query batch size. The default
603
+ batch size is 101.
586
604
587
- - The optimizer reaches 101 results. At this point, the optimizer
588
- chooses the index that has provided the most results *first* and
589
- continues reading only from that index.
605
+ - Version 2.2: Threshold is 101.
590
606
591
607
The selected index becomes the index specified in the query plan;
592
608
future iterations of this query or queries with the same query
@@ -618,7 +634,7 @@ use of the different indexes:
618
634
619
635
This returns the statistics regarding the execution of the query. For
620
636
more information on the output of :method:`explain()
621
- <cursor.explain()>` see the :doc:`/reference/explain`.
637
+ <cursor.explain()>`, see the :doc:`/reference/explain`.
622
638
623
639
.. note::
624
640
@@ -791,9 +807,9 @@ Consider the following behaviors related to cursors:
791
807
792
808
- Because the cursor is not isolated during its lifetime, intervening
793
809
write operations may result in a cursor that returns a single
794
- document [#single-document-def]_ more than once.
795
- To handle this situation, see the information on :wiki :`snapshot mode
796
- <How to do Snapshotted Queries in the Mongo Database >`.
810
+ document [#single-document-def]_ more than once. To handle this
811
+ situation, see the information on :ref :`snapshot mode
812
+ <faq-developers-isolate-cursors >`.
797
813
798
814
- The MongoDB server returns the query results in batches:
799
815
@@ -906,7 +922,8 @@ operations for more basic data aggregation operations:
906
922
907
923
- :method:`group()`
908
924
909
- - :dbcommand:`mapReduce() <mapReduce>` (See also :wiki:`MapReduce`.)
925
+ - :dbcommand:`mapReduce() <mapReduce>` (See also
926
+ :doc:`/applications/map-reduce`.)
910
927
911
928
.. index:: read operation; architecture
912
929
.. _read-operations-architecture:
0 commit comments