Details
-
Bug
-
Status: Closed
-
Critical - P2
-
Resolution: Duplicate
-
2.4.8, 2.4.10
-
None
-
None
-
ALL
-
Description
Here is the correct number of documents:
mongos> db.ad_campaigns.find({fs:2}).count()
|
4587
|
If you specify a batchSize and a sort, you get fewer than all the documents:
mongos> function cursorCount(query, batchSize) { var count = 0; var cursor = db.ad_campaigns.find(query).batchSize(batchSize); while(cursor.hasNext()) { cursor.next(); count++; }; return count } |
mongos> cursorCount({fs:2}, 100)
|
3504
|
The number of documents returned appears to be K + batchSize, for some K:
mongos> cursorCount({fs:2}, 101)
|
3505
|
mongos> cursorCount({fs:2}, 102)
|
3506
|
K (3404 in this example) happens to match the number of documents matching the query on one shard (ads1):
ads1> db.ad_campaigns.find({fs:2}).count()
|
3404
|
This relationship between K and the number of records on ads1 is borne out on other queries:
mongos> db.ad_campaigns.find({fs:5}).count()
|
9764
|
mongos> cursorCount({fs:5}, 100)
|
5249
|
ads1> db.ad_campaigns.find({fs:5}).count()
|
5149
|
If the batch size is not specified or the cursor is not sorted, the problem goes away:
mongos> db.ad_campaigns.find({fs:2}).count()
|
4587
|
mongos> cursorCount({fs:5}, 2000)
|
4587
|
mongos> var count = 0; var cursor = db.ad_campaigns.find({fs:2}).batchSize(100); while(cursor.hasNext()) { cursor.next(); count++; }; count |
4587
|
Attachments
Issue Links
- duplicates
-
SERVER-12438 batch size with an unindexed sort in the new query system is inconsistent with the old behavior
-
- Closed
-
- is related to
-
SERVER-6015 using sort() with batchSize() never returns an active cursor, therefore incomplete resultsets can be returned
-
- Closed
-
-
SERVER-7267 Batch size + sort closes the cursor
-
- Closed
-
-
SERVER-14174 If ntoreturn is a limit (rather than batch size) extra data gets buffered during plan ranking
-
- Closed
-
-
SERVER-5374 batchSize is a hard limit for an in memory sort
-
- Closed
-