[SERVER-1528] with new index skipping, nscanned may not accurately predict time cost of a query Created: 31/Jul/10 Updated: 12/Jul/16 Resolved: 04/Aug/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
With the new btree skipping implementation, currently nscanned counts the number of documents which match the query according to the index spec. But this can result in situations in which indexes which require skipping have the same nscanned as indexes not requiring skipping. One solution is to include in nscanned the number of btree entries touched during skipping. Currently there's no way to transfer that information from the btree implementation to the query optimizer, but that can be added. I can implement, but sounds like a good idea Eliot? |
| Comments |
| Comment by auto [ 04/Aug/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Eliot Horowitz (Inactive) [ 02/Aug/10 ] |
|
going to make just 1.7 early for now. |
| Comment by Eliot Horowitz (Inactive) [ 31/Jul/10 ] |
|
Yes but don't want to change that for 1.6. |