[SERVER-5032] unnecessarily large nScanned occurs during sharded $in queries with sort() and limit() Created: 22/Feb/12 Updated: 07/Mar/14 Resolved: 22/Feb/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 1.8.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | David Wasserstrum | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
A large number of nScannedObjects occurs when a sharded $in query contains both a limit() and sort() clause. For example, we have a checkins collection which is sharded by {uid: 1}and contains the index {uid: 1, _id: -1}. A db.checkins.find({uid: {$in: [400438]}}).limit(2).sort({_id: -1}) will scan just the two documents returned. db.checkins.find({uid: {$in: [400438, 32]}}).limit(2).sort({_id: -1}) will scan thousands of documents. The attachment walks through the example with an interactive console. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 22/Feb/12 ] |
| Comment by David Wasserstrum [ 22/Feb/12 ] |
|
Yes Aaron. Thank you for bringing |
| Comment by Aaron Staple [ 22/Feb/12 ] |
|
Hi David - would |