- Aggregation >
- Aggregation Pipeline >
- Aggregation Pipeline Optimization
Aggregation Pipeline Optimization¶
On this page
Aggregation pipeline operations have an optimization phase which attempts to reshape the pipeline for improved performance.
To see how the optimizer transforms a particular aggregation pipeline,
include the explain
option in the
db.collection.aggregate()
method.
Optimizations are subject to change between releases.
Projection Optimization¶
The aggregation pipeline can determine if it requires only a subset of the fields in the documents to obtain the results. If so, the pipeline will only use those required fields, reducing the amount of data passing through the pipeline.
Pipeline Sequence Optimization¶
($project
or $unset
or $addFields
or $set
) + $match
Sequence Optimization¶
For an aggregation pipeline that contains a projection stage
($project
or $unset
or
$addFields
or $set
) followed by a
$match
stage, MongoDB moves any filters in the
$match
stage that do not require values computed in the
projection stage to a new $match
stage before the
projection.
If an aggregation pipeline contains multiple projection and/or
$match
stages, MongoDB performs this optimization for each
$match
stage, moving each $match
filter before
all projection stages that the filter does not depend on.
Consider a pipeline of the following stages:
The optimizer breaks up the $match
stage into four
individual filters, one for each key in the $match
query
document. The optimizer then moves each filter before as many projection
stages as possible, creating new $match
stages as needed.
Given this example, the optimizer produces the following optimized
pipeline:
The $match
filter { avgTime: { $gt: 7 } }
depends on the
$project
stage to compute the avgTime
field. The
$project
stage is the last projection stage in this
pipeline, so the $match
filter on avgTime
could not be
moved.
The maxTime
and minTime
fields are computed in the
$addFields
stage but have no dependency on the
$project
stage. The optimizer created a new
$match
stage for the filters on these fields and placed it
before the $project
stage.
The $match
filter { name: "Joe Schmoe" }
does not
use any values computed in either the $project
or
$addFields
stages so it was moved to a new
$match
stage before both of the projection stages.
Note
After optimization, the filter { name: "Joe Schmoe" }
is in
a $match
stage at the beginning of the pipeline. This has
the added benefit of allowing the aggregation to use an index on the
name
field when initially querying the collection.
See Pipeline Operators and Indexes for more
information.
$sort
+ $match
Sequence Optimization¶
When you have a sequence with $sort
followed by a
$match
, the $match
moves before the
$sort
to minimize the number of objects to sort. For
example, if the pipeline consists of the following stages:
During the optimization phase, the optimizer transforms the sequence to the following:
$redact
+ $match
Sequence Optimization¶
When possible, when the pipeline has the $redact
stage
immediately followed by the $match
stage, the aggregation
can sometimes add a portion of the $match
stage before the
$redact
stage. If the added $match
stage is at
the start of a pipeline, the aggregation can use an index as well as
query the collection to limit the number of documents that enter the
pipeline. See Pipeline Operators and Indexes for
more information.
For example, if the pipeline consists of the following stages:
The optimizer can add the same $match
stage before the
$redact
stage:
$project
/$unset
+ $skip
Sequence Optimization¶
New in version 3.2.
When you have a sequence with $project
or $unset
followed by
$skip
, the $skip
moves before $project
. For example, if
the pipeline consists of the following stages:
During the optimization phase, the optimizer transforms the sequence to the following:
Pipeline Coalescence Optimization¶
When possible, the optimization phase coalesces a pipeline stage into its predecessor. Generally, coalescence occurs after any sequence reordering optimization.
$sort
+ $limit
Coalescence¶
Changed in version 4.0.
When a $sort
precedes a $limit
, the optimizer
can coalesce the $limit
into the $sort
if no
intervening stages modify the number of documents
(e.g. $unwind
, $group
).
MongoDB will not coalesce the $limit
into the
$sort
if there are pipeline stages that change the number of
documents between the $sort
and $limit
stages..
For example, if the pipeline consists of the following stages:
During the optimization phase, the optimizer coalesces the sequence to the following:
This allows the sort operation to only maintain the
top n
results as it progresses, where n
is the specified limit,
and MongoDB only needs to store n
items in memory
[1]. See $sort Operator and Memory for more
information.
Sequence Optimization with $skip
If there is a $skip
stage between the $sort
and $limit
stages, MongoDB will coalesce the
$limit
into the $sort
stage and increase the
$limit
value by the $skip
amount. See
$sort + $skip + $limit Sequence for an example.
[1] | The optimization will still apply when
allowDiskUse is true and the n items exceed the
aggregation memory limit. |
$limit
+ $limit
Coalescence¶
When a $limit
immediately follows another
$limit
, the two stages can coalesce into a single
$limit
where the limit amount is the smaller of the two
initial limit amounts. For example, a pipeline contains the following
sequence:
Then the second $limit
stage can coalesce into the first
$limit
stage and result in a single $limit
stage where the limit amount 10
is the minimum of the two initial
limits 100
and 10
.
$skip
+ $skip
Coalescence¶
When a $skip
immediately follows another $skip
,
the two stages can coalesce into a single $skip
where the
skip amount is the sum of the two initial skip amounts. For example, a
pipeline contains the following sequence:
Then the second $skip
stage can coalesce into the first
$skip
stage and result in a single $skip
stage where the skip amount 7
is the sum of the two initial
limits 5
and 2
.
$match
+ $match
Coalescence¶
When a $match
immediately follows another
$match
, the two stages can coalesce into a single
$match
combining the conditions with an
$and
. For example, a pipeline contains the following
sequence:
Then the second $match
stage can coalesce into the first
$match
stage and result in a single $match
stage
$lookup
+ $unwind
Coalescence¶
New in version 3.2.
When a $unwind
immediately follows another
$lookup
, and the $unwind
operates on the as
field of the $lookup
, the optimizer can coalesce the
$unwind
into the $lookup
stage. This avoids
creating large intermediate documents.
For example, a pipeline contains the following sequence:
The optimizer can coalesce the $unwind
stage into the
$lookup
stage. If you run the aggregation with explain
option, the explain
output shows the coalesced stage:
Example¶
$sort
+ $skip
+ $limit
Sequence¶
A pipeline contains a sequence of $sort
followed by a
$skip
followed by a $limit
:
The optimizer performs $sort + $limit Coalescence to transforms the sequence to the following:
MongoDB increases the $limit
amount with the reordering.
See also
explain
option in the
db.collection.aggregate()