lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [jira] Commented: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
Date Tue, 09 Dec 2008 10:27:12 GMT

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 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...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message