Correction: the doc order is fine. My test was based on the existing
'TestMultiSearcher', and I hadn't noticed the swapping of the index order
here:
// VITAL STEP:adding the searcher for the empty index first, before
the searcher for the populated index
searchers[0] = new IndexSear
Peter Keegan wrote:
Oops. I meant to say: Does this mean that an IndexSearcher constructed from
a MultiReader doesn't merge the search results and sort the results as if
there was only one index?
It doesn't have to, since a MultiReader *is* a single index.
A quick test indicates that it does
On 4/11/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
> Oops. I meant to say: Does this mean that an IndexSearcher constructed from
> a MultiReader doesn't merge the search results and sort the results as if
> there was only one index?
That's how I answered it.
A single search is done... the "mergin
Oops. I meant to say: Does this mean that an IndexSearcher constructed from
a MultiReader doesn't merge the search results and sort the results as if
there was only one index?
A quick test indicates that it does merge the results properly, however
there is a difference in the order of documents wi
On 4/11/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
> Does this mean that MultiReader doesn't merge the search results and sort
> the results as if there was only one index?
Correct, it doesn't. It supports the lower level primitives like
TermEnum and TermDocs that searches use to run. A term qu
Does this mean that MultiReader doesn't merge the search results and sort
the results as if there was only one index? If not, does it simply
concatenate the results?
Peter
On 4/11/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
> On 4/11/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
> > Could you
On 4/11/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
> Could you explain why an IndexSearcher constructed from multiple readers is
> faster than a MultiSearcher constructed from same readers?
The "convergence layer" is a level lower for a MultiReader vs a MultiSearcher.
A MultiReader is an IndexRe
Yonik,
Could you explain why an IndexSearcher constructed from multiple readers is
faster than a MultiSearcher constructed from same readers?
Thanks,
Peter
On 4/10/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
> On 4/10/06, oramas martín <[EMAIL PROTECTED]> wrote:
> > Is there any performance
On 4/10/06, oramas martín <[EMAIL PROTECTED]> wrote:
> Is there any performance (or other) difference between using an
> IndexSearcher initialized with a MultiReader instead of using a
> MultiSearcher?
Yes, the IndexSearcher(MultiReader) solution will be faster.
-Yonik
http://incubator.apache.org
Is there any performance (or other) difference between using an
IndexSearcher initialized with a MultiReader instead of using a
MultiSearcher?
Thanks,
Jose L. Oramas
f indexes, I get the right document back.
(i.e. my hits object gives me a lucene ID of 5 for my first hit,
and if I ask the multireader for document with lucene ID 5, I get
the same document)
Is this always going to be the case? Do I simply have to ensure
that I open the MultiReader and Mu
ts object gives me a lucene ID of 5 for my first hit, and if I
ask the multireader for document with lucene ID 5, I get the same
document)
Is this always going to be the case? Do I simply have to ensure that I
open the MultiReader and MultiSearcher with the indexes in the right order
to ensure th
12 matches
Mail list logo
