As a compromise, you can base your custom sort function on values of stored
fields in the same index - as opposed to fetching them from an external
data store, or relying on internal sorting implementation in Lucene. It
will still be relatively slow, but not nearly as slow as going out to a
DB... t
Sure, you can write a custom function, see:
https://cwiki.apache.org/confluence/display/solr/Function+Queries
And you can invoke your custom function since sorting by function is supported.
But my point remains. To be performant, you'll have to cache the
results. Which is what's happening alread
Hi pals,
I have created an index out of about 1000 documents. When I searched through
the index, I got an accuracy of around 37.7%, then I made another index file
with same documents. So, the number of index files doubled and surprisingly,
the accuracy enhanced to 55%!! Making the index for anothe
On Mon, Jun 23, 2014 at 3:56 PM, Ravikumar Govindarajan
wrote:
> Yes, we can get the top-50 docs finally. I am not denying that.
>
> I will probably re-phrase my question. Apologize if I am not clear
>
> How do we ensure global sort-order during search across all segments of the
> index, when usin
25 June 2014, Apache Lucene™ 4.9.0 available
The Lucene PMC is pleased to announce the release of Apache Lucene 4.9.0
Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-t
Hi,
Thanks for your reply.
Actually, I am evaluating both approaches.
With the sort being performed on a field indexed in Lucene itself, my concern
is with the FieldCache. Very quickly, for multiple clients executing in
parallel, it bumps up to 8-10GB. This is for 4-5 different Sort fields usi
