Never rely on lucene internal doc ids. Use your own. Lucene searches
on unique ids are of course very fast.
--
Ian.
On Fri, Mar 1, 2013 at 9:51 AM, Ramprakash Ramamoorthy
wrote:
> Hello team,
>
> I have a query and I am explaining it as below.
>
> Objective : To split index and sto
You're probably better off asking Solr questions on the solr list.
But if you really need the 20 hits starting at 100 i.e. page
number 5 you'd better rethink your requirements and your indexing
strategy.
--
Ian.
On Fri, Mar 1, 2013 at 6:48 AM, dizh wrote:
>
> Hi，All：
>
> I want to ask
On Fri, Mar 1, 2013 at 4:46 PM, Ian Lea wrote:
> Never rely on lucene internal doc ids. Use your own. Lucene searches
> on unique ids are of course very fast.
>
Point taken Ian. So in case I have 100 matching doc Ids and so the next
step is either collate the 100 docIds into a query with OR, o
On 2/28/2013 5:05 PM, Uwe Schindler wrote:
... Collector instead of HitCollector (like your ancient Lucene from 2.4), you have to
respect the new semantics that are *different* to old HitCollector. Collector works with
low-level atomic readers (also in Lucene 3.x), the calls to the "collect(in
The slowdown happens not on making the doc ids absolute (it is just an
addition), the slowdown appears when you retrieve the stored fields on the
top-level reader (because the composite top-level reader has to do a binary
search in the reader tree to find the correct reader). This answer was rel
On 03/01/2013 07:56 AM, Uwe Schindler wrote:
The slowdown happens not on making the doc ids absolute (it is just an
addition), the slowdown appears when you retrieve the stored fields on the
top-level reader (because the composite top-level reader has to do a binary
search in the reader tree t
Hi,
I've seen some changes in trunk regarding the data format of Lucene's
FST-based suggesters, and wonder whether the automata created by trunk
builds/next Lucene version are/will be binary-compatible to the ones
created with the current release, or whether any magic versioning is
taking plac
