I don't think rounding will affect cache hits in either case _unless_
the input point for different queries can be very close to each other.
Think of the filter cache as being composed of a map where the key
is the (raw) filter query and the value is the set of documents in your
corpus that satisfy it.
So the only time rounding would help, is if it's likely that two
users enter very similar points at query time, i.e.
89.1234 and 89.1236. If you're giving them a set of choices
that are pre-defined (city center, say), then the values should be
identical to all the decimal places so rounding doesn't do you much
good.
You say you can tolerate some slop, so using bounding box might
speed up your queries...
Best
Erick
On Fri, Aug 3, 2012 at 4:56 AM, Thomas Heigl <tho...@umschalt.com> wrote:
> Hey all,
>
> Our production system is heavily optimized for caching and nearly all parts
> of queries are satisfied by filter caches. The only filter that varies a
> lot from user to user is the location and distance. Currently we use the
> default location field type and index lat/long coordinates as we get them
> from Geonames and GMaps with varying decimal precision.
>
> My question is: Does it make sense to round these coordinates (a) while
> indexing and/or (b) while querying to optimize cache hits? Our maximum
> required resolution for geo queries is 1km and we can tolerate minor errors
> so I could round to two decimal points for most of our queries.
>
> E.g. Instead of querying like this
>
> fq=_query_:"{!geofilt sfield=user.location_p pt=48.19815,16.3943
>> d=50.0}"&sfield=user.location_p&pt=48.1981,16.394
>
>
> we would round to
>
> fq=_query_:"{!geofilt sfield=user.location_p pt=48.19,16.39
>> d=50.0}"&sfield=user.location_p&pt=48.19,16.39
>
>
> Any feedback would be greatly appreciated.
>
> Cheers,
>
> Thomas
