[SERVER-16592] bad order search logic in Geonear Created: 18/Dec/14 Updated: 09/Jan/15 Resolved: 09/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo, Index Maintenance, Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | guipulsar | Assignee: | Siyuan Zhou |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||
| Operating System: | ALL | ||||||||||
| Steps To Reproduce: |
|
||||||||||
| Participants: | |||||||||||
| Description |
|
Hi , consider this query , tested with all possible indexation cases
There is no code_postal value with 2 , the query take very long time to search distance first... regards |
| Comments |
| Comment by guipulsar [ 31/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
if you consider its not a bug perhaps it could be a good idea to write some words about it in the doc because thats at least unclear from my point of vue | |||||||||||||||||||||||||||||||||
| Comment by Siyuan Zhou [ 30/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
Hi pulsar, It's not a bug. The geo only search works by design, because running geo query with compound index { code_postal: 1 , loc : "2dsphere" } cannot use the index. The b-tree entries of compound index are ordered by code_postal first. If two documents have the same code_postal, then they will be ordered by loc using geohash. There is no total order of loc in b-tree, so geo query without code_postal doesn't know which portion of the b-tree should be scanned. If you have any questions about geo query or MonogDB generally, the google group and stackoverflow is the best place to ask, since there are many active MongoDB users and experts in the community. | |||||||||||||||||||||||||||||||||
| Comment by guipulsar [ 22/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
i am on 2.6.6 , ) ); you will have an error : I guess its a related bug..I'm facing many pb with GeoNear , | |||||||||||||||||||||||||||||||||
| Comment by Siyuan Zhou [ 22/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
pulsar, thanks for reporting this issue. What version are you using? I am able to reproduce this problem on 2.8.0-rc3 with the following $near query.
The compound index { loc: "2dsphere", zip_code: 1 } is very slow in this case, but {zip_code: 1, loc: "2dsphere"} works as expected. From the explain(), it shows that index scan works much faster with the index on {zip_code: 1, loc: "2dsphere"}. As a workaround, building an index on {zip_code: 1, loc: "2dsphere"} should work for you. PS: in 2.8.0-rc3, the execution time spent on geo near stage (and its sub-stages) is always shown as 0, this bug has been filed in | |||||||||||||||||||||||||||||||||
| Comment by guipulsar [ 22/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
actualy time consuming decreased with a compund index on loc and code_postal but still very slow, because it should be very speed to see thats code_postal match nothing right ? Here my actual output index with coresponding explain:
| |||||||||||||||||||||||||||||||||
| Comment by Ramon Fernandez Marina [ 21/Dec/14 ] | |||||||||||||||||||||||||||||||||
|
pulsar, can you please post the output of
? |