I am getting this error "InternalError No plan available to provide stats" when I use explain with aggregation framework. Below is the output I got.
But If I run the query without explain and then again run it with explain, it does not give this error and have the indexes used in the plans section.
Is the aggregation query not running in background when explain option is present? Does aggregation also follows the same strategy mentioned here: http://docs.mongodb.org/
Do I always have to run the query first in order to check if some index will be used or not? If this the case is it possible to improve upon this behavior?
> db.product.aggregate([{$match: {productId: {$lt:10000}, price: {$lt:3}}},{$group: {_id: "$productId", avgRating: {$avg: "$reviews.rating"}}}],{
{
"stages" : [
{
"$cursor" : {
"query" : {
"productId" : {
"$lt" : 10000
},
"price" : {
"$lt" : 3
}
},
"fields" : {
"productId" : 1,
"reviews.rating" : 1,
"_id" : 0
},
"planError" : "InternalError No plan available to provide stats"
}
},
{
"$group" : {
"_id" : "$productId",
"avgRating" : {
"$avg" : "$reviews.rating"
}
}
}
],
"ok" : 1
}
Thanks,
It's hard to answer without knowing which version you are using.
Asya: "InternalError No plan available to provide stats" is an error message from the MultiPlanRunner. I suspect in your reproduction attempt you only had index relevant to the query; you need both the {price:1} index and the {productId:1} index in order to hit this.
Which version are you using?
I am using mongodb v2.6.1
I just tried to reproduce this using 2.6.1 and I got a plan - do you remember what you did before running that aggregate that gave this error?
I'm wondering if it's dependent on something I need to emulate - I created new data, new indexes and ran aggregate with explain and it gave me a plan, so I definitely never ran any query on that collection/using that index...
Thanks for taking a look at this. Will the size of data set will make any difference?
I tried this again by simply shutting down mongod process and running the aggregation operation again in mongo shell. I got the same error.
My collection stats:
> db.product.stats()
{
"ns" : "testdb.product",
"count" : 394758025,
"size" : 644281293680,
"avgObjSize" : 1632,
"storageSize" : 651087568192,
"numExtents" : 324,
"nindexes" : 5,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1,
"systemFlags" : 1,
"userFlags" : 1,
"totalIndexSize" : 67416548864,
"indexSizes" : {
"_id_" : 17409328496,
"productId_1" : 9930921168,
"category_1_manufacturer_1" : 20195414960,
"price_1" : 9943193344,
"mfgDate_1" : 9937690896
},
"ok" : 1
}
Thanks,
Abhi: I can also reproduce this issue in 2.6.1, but not in 2.6.2/2.6.3 or 2.7.3. Could you try upgrading to 2.6.3 and see if you still encounter it?
Abhi: my mistake, I can indeed reproduce this on 2.6.2/2.6.3 (I had my 2.6.x binaries replaced with 2.7.x binaries by accident), so upgrading to one of those versions won't fix this for you. I filed <https://jira.mongodb.org/
We are seeing this same error message when trying to optimize some pretty heavy aggregate queries. I saw the bug filed in jira is still labeled as Needs Triage. If anyone had to take a guess, is this just a display error when explaining an aggregate query or is it possible that the query planner is actually failing to generate a plan and use the correct indexes? If it is the latter would you recommend downgrading (or testing 2.7 binaries) to avoid this issue?
This bug is a "display error" in the sense that it only affects aggregate operations with {explain:true}. Index selection for aggregation queries works as normal in versions affected by this bug, thus you shouldn't need to downgrade.
As indicated in the ticket description, this bug only affects explain for aggregation operations on uncached queries. Hence, one partial workaround for the issue is to run your aggregation operation without {explain:true}, and then run the aggregation operation again with {explain:true}. If the query plan is cacheable, then the first run will choose and cache the query plan, and the second run will use the query plan retrieved from the cache.
댓글 없음:
댓글 쓰기