-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.4.4
-
Query Optimization
-
ALL
-
-
Query 2018-05-21
This can lead to various problems such as:
- the following query does not include a SORT_KEY_GENERATOR stage:
db.sharded.explain().find().sort({a: 1});
This is because the explain path on mongos diverges from the regular, non-explain path pretty early. In particular, the non-explain path will transform the query sent to the shards in transformQueryForShards. This transformation does not happen in the explain path, and causes us to leave off the projection {$sortKey: 1} which will signal to the shards that we intend to merge the sorted output on mongos.
- When using .explain("executionStats") on a query that includes a skip phase on sharded collection, the skip phase is applied separately at each queried shard. The result is each individual shard's nReturned is reduced by the skip_count, so the overall nReturned is reduced by (skip_count * shard_count).
- An "executionStats" explain with a limit is subject to a similar bug, as described in
SERVER-32555.
- is duplicated by
-
SERVER-32555 executionStats.nReturned incorrect for sharded query with limit
- Closed
-
SERVER-33895 Not needed SORT_KEY_GENERATOR in aggregation explain output
- Closed
-
SERVER-82471 Make sure explain.find issued on mongos sends a modified query to the shards
- Closed
- is related to
-
SERVER-34736 Make ClusterFind::explain directly call scatterGather() rather than go through Strategy::explainFind
- Closed
- related to
-
SERVER-32563 explain output for sharded count command is incorrect
- Backlog
-
SERVER-34338 find explain in legacy query path on mongos does not retry on StaleShardVersion
- Closed
-
SERVER-82218 Unify explain and execution path in sharded_agg_helpers
- Closed