|
I see your point, though I think it's not necessarily bad to be able to show users that it doesn't have an effect on the explained query. I think this is a side effect of the explain design: our current explain implementation (as documented, though I don't think it's ideal) runs through the entire result set and returns execution stats for the entire query, but perhaps in the future we can explain one batch at a time, and/or indicate in the command response how each of the options would change execution of the query (note also that presence of the exhaust flag, the "no timeout" flag, and the tailable flag also don't have any effect on the explained query, but explain accepts them still).
|
|
I disagree on both counts. The legacy $explain path ignores batchSize, and I think that this is the correct design and that the explain command should follow suit (and I believe it's not necessary to make the shell and drivers conditionally include this field). The same way that users today can tack a .explain() onto an existing call to db.collection.find(blah).blah().batchSize().blah() and see an explain of the same query, users of 2.8 should be able to use the same cursor methods against an "explainable collection" and see the explain for the same query.
|