We can definitely do that, its actually something that I want to do (once we
can derive the bounding box from the distance). Its the same question
between "range" filter and "numeric_range" filter. The first uses the index
data to do the range check, the second does only in memory range checks.
Some times the fist one is faster, and sometimes the second one is.
For most typical cases, where the geo functionality is driven by a main
query that already narrows down the search, the in memory checks will be
faster. It might even be faster in the match_all case (depends on the
distribution of data).
But, we can definitely have an option to do "indexed" based range checks for
bounding box (will require also indexing the lat/lon). Note, this will not
work with multiple locations per doc (unless nested mapping is used). Can
you open an issue?
On Tue, Sep 13, 2011 at 5:18 PM, Josh Devins email@example.com wrote:
On second thought, I think geohash might be more than necessary. You
mention that what is in master right now relies on first doing a
bounding box filter, then the range filter. Why not use a range query
on the minimum bounding box of the geo_distance radius to narrow this
down in Lucene first, then what you have in memory you can just apply
the regular geo_distance filter? Not sure about performance, but it
would then not require a pre-calculated geohash in the index.