[SERVER-2274] Performance of count() on range check queries is worse than it should be Created: 22/Dec/10 Updated: 07/Mar/14 Resolved: 26/Oct/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 1.6.5 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Remon van Vliet | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 57 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Any |
||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Using the test script below this script reports about 50ms of time taken for the count query in the script. This is way too slow for a query that the query optimizer should resolve to a direct bsearch on the index, or so I assume. use test db.values.drop(); ); for (var i = 1; i <= 100000; i++) db.values.save( {value : i}); var t1 = new Date().getTime(); (t2 - t1); |
| Comments |
| Comment by Remon van Vliet [ 07/Jun/11 ] |
|
I think the problem might be that mongo's btrees aren't counted btrees which might complicate optimizing this. As a result we'd either need a "counted" flag in index creation (e.g. "ensureIndex( {field:1}, {counted:1})") if it's a big memory hit, or just add it if it isn't. If memory serves it requires an extra counter 64-bit integer in the nod for each subnode. Eliot can probably explain better than me |
| Comment by Lennart Koopmann [ 12/May/11 ] |
|
+1 What is the status on this? We need to work around this stuff in Graylog2 because it is too slow. |
| Comment by Remon van Vliet [ 18/Feb/11 ] |
|
Alright, thanks. We'll have to look into a workaround for the time being then. |
| Comment by Eliot Horowitz (Inactive) [ 18/Feb/11 ] |
|
Unfortunately nothing more specific. |
| Comment by Remon van Vliet [ 18/Feb/11 ] |
|
Any more specific ETA on this? What's the scope and timeline of "2011 - phase 1"? |