[SERVER-4327] allow dummy table scans in no table scan mode Created: 18/Nov/11 Updated: 28/Jan/15 Resolved: 28/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | David Storch |
| Resolution: | Incomplete | Votes: | 1 |
| Labels: | query_triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Implement what I described here:
Also audit additional notablescan functionality (see SERVER-2222). |
| Comments |
| Comment by David Storch [ 28/Jan/15 ] | |
|
The new query system does not have any concept of a "dummy table scan". As far as I can tell, this refers to queries that logically cannot have any matches. The query db.docs.find({arr: {$in: []}}) for example, will always have a result size of 0. The old query system would short-circuit the execution of such queries. The query system written for 2.6, on the other hand, will always perform a table scan if the query cannot be indexed. Therefore, this ticket is no longer relevant. Closing as Incomplete. | |
| Comment by Aaron Staple [ 07/Mar/13 ] | |
|
We should perform the audit in 2.5.x and prioritize any remaining work. | |
| Comment by Aaron Staple [ 19/Jan/12 ] | |
|
Still need to audit additional notablescan functionality as mentioned in the description of this ticket. | |
| Comment by auto [ 19/Jan/12 ] | |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: | |
| Comment by auto [ 19/Jan/12 ] | |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: | |
| Comment by Colin Howe [ 19/Nov/11 ] | |
|
This would be really good for us. It would stop a query like:
From raising a table scan exception. |