Awesome!
Be sure to "watch" the JIRA issue as it develops. The patch will improve
(I've already improved it but not posted it) and one day a solution is bound
to get committed.
~ David
Jeff Wartes wrote
> This is actually pretty far afield from my original subject, but it turns
> out that I al
This is actually pretty far afield from my original subject, but it turns
out that I also had issues with NRT and multi-field geospatial
performance in Solr 4, so I'll follow that up.
I've been testing and working with David's SOLR-5170 patch ever since he
posted it, and I pushed it into produc
The distance sorting code in SOLR-2155 is roughly equivalent to the code that
RPT uses (RPT has its lineage in SOLR-2155 after all). I just reviewed it
to double-check. It's possible the behavior is slightly better in SOLR-2155
because the cache (a Solr cache) contains normal hard-references wher
We have been using 2155 for over 6 months in production with over 2M hits
every 10 minutes. No OOM yet.
2155 seems great, and would this issue be any worse than 2155?
On Wed, Aug 14, 2013 at 4:08 PM, Jeff Wartes wrote:
>
> Hm, "Give me all the stores that only have branches in this area" migh
Hm, "Give me all the stores that only have branches in this area" might be
a plausible use case for farthest distance.
That's essentially a "contains" question though, so maybe that's already
supported? I guess it depends on how contains/intersects/etc handle
multi-values. I feel like multi-value
On 8/14/13 2:26 PM, "Jeff Wartes" wrote:
>
>I'm still pondering aggregate-type operations for scoring multi-valued
>fields (original thread: http://goo.gl/zOX53f ), and it occurred to me
>that distance-sort with SpatialRecursivePrefixTreeFieldType must be doing
>something like that.
It isn't.
