Mark Miller wrote:
Michael McCandless wrote:
Mark Miller wrote:
Mark Miller wrote:
Which new sort stuff are you referring to? Is it LUCENE-1471?
Yes. First thing I did was try and patch this in, but the sort
tests failed. It would be the right order, but like the two
center docs would be reversed or something. No time to dig in, so
I just switch to the trunk MultiSearcher and all tests passed
except for the two with the above issues.
Spoke too soon. Wasnt LUCENE-1471's fault, it was just hitting
different aspects of an issue thats messed up with the old
MultiSearcher as well.
OK. If you're building on LUCENE-1471, make sure you start from
the first patch. It'd be good to factor that logic (2nd pqueue for
merging) out so it can be reused b/w IndexSearcher & MultiSearcher.
I actually worked with the second. I'll take a look at the first
instead. I'm sticking with using the MultiSearcher for the first
patch - it can be worked out later if it speed things up.
OK. And, the first now has a 2nd iteration (factors
ParallelMultiSearcher to do the merge sort too).
Does returning by document id order even make sense with this
though? Did it make sense with MultiSearcher? They are pseudo ids
(mapped), so it almost seems I can't support that right...it would
depend on the order of the readers.
I think it does make sense (it's well defined). This is what the
SubsearcherTopDocs.convertTopDoc method is doing (in the
multisearcher.take2.patch on LUCENE-1471).
In fact, returning by document order is a particularly trivial sort,
since you'd just have to concatenate the results coming out of the
pqueues (ie you wouldn't need a 2nd pqueue). In fact, any SortField[]
that contains a SortField.FIELD_DOC could be truncated since that sort
order is "total". But these are minor optimizations which we
shouldn't worry about for now...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
