@@ -20,7 +20,8 @@ For a query, the MongoDB query optimizer chooses and caches the most
20
20
efficient query plan given the available indexes. The evaluation of the
21
21
most efficient query plan is based on the number of "work units"
22
22
(``works``) performed by the query execution plan when the query planner
23
- evaluates candidate plans.
23
+ evaluates candidate plans. In general, the MongoDB query planner
24
+ selects query plans with fewer ``works`` as the winning plan.
24
25
25
26
The associated plan cache entry is used for subsequent queries with the
26
27
same query shape.
@@ -34,7 +35,8 @@ The following diagram illustrates the query planner logic:
34
35
Plan Cache Entry State
35
36
~~~~~~~~~~~~~~~~~~~~~~
36
37
37
- Starting in MongoDB 4.2, the cache entry is associated with a state:
38
+ Starting in MongoDB 4.2, each query shape is associated with one of three states
39
+ in the cache:
38
40
39
41
.. list-table::
40
42
:header-rows: 1
@@ -49,13 +51,13 @@ Starting in MongoDB 4.2, the cache entry is associated with a state:
49
51
50
52
No entry for this shape exists in the cache.
51
53
52
- For a query, if the cache entry state for a shape is
54
+ For a query, if the cache entry state for a query shape is
53
55
:ref:`Missing <cache-entry-missing>`:
54
56
55
57
#. Candidate plans are evaluated and a winning plan is selected.
56
58
57
- #. The selected plan is added to the cache in :ref:`Inactive
58
- <cache-entry-inactive>` state with its ``works`` value.
59
+ #. The cache creates an entry for the query shape in state :ref:`Inactive
60
+ <cache-entry-inactive>` with its ``works`` value.
59
61
60
62
* - :ref:`Inactive <cache-entry-inactive>`
61
63
0 commit comments