[SERVER-17279] Intersect bounds over non-geo field of compound geo index Created: 13/Feb/15 Updated: 20/May/15 Resolved: 20/May/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | 3.0.0-rc8 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
If non-geo fields are not multikey index, we can intersect bounds over non-geo field of compound geo index. Although geo index generates more than one geohash index key for a document, geo index is not "multikey" in terms of query planning, because the predicate of geo field is limited to the same semantic of "$elemMatch", i.e. whether any geohash key of a document is in these intervals. Thus, it's possible to intersect bounds over non-geo field of compound geo index, if they are not "multikey". |
| Comments |
| Comment by David Storch [ 20/May/15 ] |
|
For a compound geo index like {a: 1, b: "2dsphere"}, it can be the case that indexing the geometry stored in field "b" can generate multiple index keys even though there is just a single scalar value for "a". Fixing this in a more general way requires the infrastructure described by |