[SERVER-790] Sort (Ascending|Descending) on non-indexed field (works|asserts) Created: 19/Mar/10 Updated: 07/Mar/14 Resolved: 19/Mar/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 1.2.4, 1.3.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | John Demme | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu 9.10 x64 |
||
| Participants: |
| Description |
|
If I run a sort query (with limit) on a collection in ascending order, everything operates properly: > db.signatures.find().sort( {numbb:1}).limit(10) { "_id" : ObjectId("4b980bcb5506ca18cc00000d"), "numbb" : 2, "symbol" : "gen_raw_REG", "type" : "ssig", "signature" : BinData type: 2 len: 67 }..... But I actually want descending order: ).limit(10) Curiously, a smaller limit works properly: ).limit(3) { "_id" : ObjectId("4b980ed75506ca18cc02d6fb"), "_types" : [ "Signature" ], "symbol" : "_ZN8LargeNet13doBuildInsideEv", "numbb" : 6323, "_cls" : "Signature", "signature" : BinData type: 2 len: 2364674, "type" : "ssig" }.... For reference, .limit(4) is apparently too large. If there's a good reason for this, so be it. I'm guessing, however, that this is due to the query optimizer doing quite different things depending on sort order. |
| Comments |
| Comment by Jan Stastny [ 20/Apr/11 ] |
|
Eliot, |
| Comment by Eliot Horowitz (Inactive) [ 19/Apr/11 ] |
|
Currently no. |
| Comment by Jan Stastny [ 19/Apr/11 ] |
|
Is there a way to change the limit of 1 MB? |
| Comment by Eliot Horowitz (Inactive) [ 19/Mar/10 ] |
|
there is a 1mb limit for how much data we'll hold in memory to sort. |