Details
-
New Feature
-
Resolution: Duplicate
-
Major - P3
-
None
-
None
-
None
-
Fully Compatible
Description
In select cases, it would be beneficial to users if they could make use of covered queries as the first stage of a pipeline aggregation. One use case would be for aggregating the metadata on a collection with a very large blob on each document, where the blob is not part of the query.
My suggestion would be that if an aggregations starts off with a combination of $match, $sort, and $project, with the $project required, then it be considered for a covered query by the planner. Any of these combinations should be directly translatable to a .find() which does have the potential to be covered.
Example:
db.coll.insert({
|
created: ISODate('2014-07-04'),
|
type: 'Blog',
|
size: 1234567,
|
title: 'My Title',
|
body: '<2MB text string>',
|
})
|
|
|
db.coll.ensureIndex({created:1, type: 1, size:1})
|
|
|
db.coll.aggregate([
|
{$match: {created: {$gte: ISODate('2014-01-01')}}},
|
{$project: {size: 1, type:1, _id :0}},
|
// Up to here is a covered query.
|
{$group: {_id: '$type',
|
total_size: {$sum: '$size'},
|
count: {$sum: 1}}}
|
])
|
Attachments
Issue Links
- duplicates
-
SERVER-12015 Reenable use of covering indexes with aggregation
-
- Closed
-