[SERVER-4914] avoid scanning a dummy shard for an unsatisfiable query Created: 08/Feb/12 Updated: 06/Dec/22 Resolved: 15/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | lamont-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Participants: | |||||||||
| Description |
|
As part of the I believe the current behavior is functionally correct, but we are querying the dummy shard unnecessarily for these unsatisfiable queries. The current implementations of count and find have explicit assertions that the returned list of shards is not empty. It would make sense to ensure/check that all callers for getShardsForQuery() can handle an empty set of shards. Some of the tricky cases I can see are:
I will add some additional comments indicating which pieces of code will need to be touched to change the behavior of getShardsForQuery(). |
| Comments |
| Comment by Aaron Staple [ 08/Feb/12 ] |
|
It's just a logical check, in the sharding case independent of the data. There are two types of checks applied:
See above commit for relevant pointers in the code. |
| Comment by auto [ 08/Feb/12 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by Greg Studer [ 08/Feb/12 ] |
|
Is the "can be satisfied" test related at all to the actual distribution of documents, sharded or not, or is it just a logical check? |