[SERVER-849] Geospatial Indexing -- Slow Cases Created: 30/Mar/10 Updated: 19/May/14 Resolved: 08/Jul/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Kyle Banker | Assignee: | Richard Kreuter (Inactive) |
| Resolution: | Won't Fix | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Participants: |
| Description |
|
Certain coordinates result in slow queries. Not sure why. Dataset attached. Fast: ); Slow: ); Fast: ); |
| Comments |
| Comment by Richard Kreuter (Inactive) [ 08/Jul/10 ] |
|
As mentioned, this is mostly tripping a worst-case edge in the geohashing algorithm. For now, we recommend that applications use the maxDistance option to geoNear to avoid searching very large spaces. The syntax looks like this: db.runCommand ( { geoNear : "people" , near : [65, -97.11291], num : 2, maxDistance:8 }); |
| Comment by Richard Kreuter (Inactive) [ 07/Jul/10 ] |
|
This is just an edge case in the algorithm that has bad performance. > db.runCommand ( { geoNear : "people" , near : [65, -97.11291], num : 1}); } , |
| Comment by Richard Kreuter (Inactive) [ 07/Jul/10 ] |
|
Visualization of data set. Note: this diagram is a plot of 1.89M location points. |
| Comment by Kyle Banker [ 30/Mar/10 ] |
|
Sample data. |