[SERVER-1021] if scanAndOrder and full index scan are both options, may want to always try both Created: 14/Apr/10 Updated: 12/Jul/16 Resolved: 07/Jan/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
think about if there are different cases where we should adjust this policy see SUPPORT-33 for example |
| Comments |
| Comment by Aaron Staple [ 14/Apr/10 ] |
|
So depending on the data we can sometimes do scan and order and sometimes can't, even though the queries are basically the same. We decide if a scan is taking too long by comparing nscanned to the last similar query. In the problem case here the last similar query scanned all documents (which was optimal b/c scan and order would use too much memory), so we don't notice a problem. |
| Comment by Eliot Horowitz (Inactive) [ 14/Apr/10 ] |
|
do you think sometimes its picking the right one and sometimes wrong? |