[SERVER-3277] More specific explain() for geo queries Created: 16/Jun/11 Updated: 12/Jul/16 Resolved: 22/Nov/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo |
| Affects Version/s: | 1.8.1 |
| Fix Version/s: | 2.1.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kyle Banker | Assignee: | Greg Studer |
| 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 |
|
Suppose you have two compound geo indexes defined on the same collection. For instance: {loc: '2d', day: 1} {loc: '2d', year: 1}Currently, the explain() output for queries that should use these indexes is deficient the following ways: 1. The exact index being used isn't noted. All we get is the cursor type: GeoSearchCursor. 2. The index bound aren't provided for either field. This makes it impossible to know whether the compound index is even worth maintaining. For instance: "cursor" : "GeoSearchCursor", |
| Comments |
| Comment by Greg Studer [ 22/Nov/11 ] |
|
Resolving as fixed as in 2.1, explain() bounds are much more informative (spatial regions searched are given). Multi-geo-index per collection is tracked in |
| Comment by auto [ 27/Jul/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: change name of extra explain function for cursor - |
| Comment by auto [ 27/Jul/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: output the regions searched in explain for 2d searches - |
| Comment by auto [ 27/Jul/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: allow custom explain extensions |
| Comment by auto [ 27/Jul/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: tracking for fixes for |
| Comment by Greg Studer [ 17/Jun/11 ] |
|
This is technically not supported, since only one index per db is currently supported. Agree that this is an enhancement worth doing though - it's a pain point. The additional index information is only annotated, the benefit is not in restricting the query space but speeding up the filtering of results by placing the data in the index key. We'll have to change the query algorithm to do something like haystack in order to take further advantage of it. |