[ 
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659240#action_12659240
 ] 

Michael McCandless commented on LUCENE-1483:
--------------------------------------------


Given how different the results are, depending on how many segments
index has, queue size, how many hits search gets, etc., I think we
need a dynamic solution, meaning in certain situations (many hits,
small queue depth, small number of large segments) you use ORD but
other times you use ORDDEM.

So I'm thinking setNextReader should return a new comparator?  Often
it would simply return itself, but if it deems it worthwhile to switch
eg from ORD to ORDDEM it would switch to ORDDEM and return that.

EG for real-time search we may have a tail of a zillion small
segments...

Then I also thought of a wild possible change: when doing searching,
it'd be best to visit the segments from largest to smallest, doing ORD
in the beginning and switching to ORDDEM at some point.  So, could we
do this?  I think we only "require" in-order docs within a segment, so
could we switch up segment order.  We'd need to fix setNextReader API
to take in reader & docBase.  Would that work?



> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
>                 Key: LUCENE-1483
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1483
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.9
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, 
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, 
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, 
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, 
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, 
> LUCENE-1483.patch, sortBench.py, sortCollate.py
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing 
> for individual segment reloading on reopen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to