[
https://issues.apache.org/jira/browse/LUCENE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977379#action_12977379
]
Michael McCandless commented on LUCENE-2766:
--------------------------------------------
bq. Or reworded: is there any reason we shouldn't actually only support this
way going forwards in the future?
+1 to requiring that PR only handle the sync'd case.
In fact... I think PR should only support atomic readers, and we can have sugar
(static method) somewhere that can take N sync'd composite readers, get their
subs, assert that they are "sync'd", and make a MultiReader of all the
ParallelReaders against the aligned subs (basically the same as the patch here).
Ie, once we only support the sync'd case, I don't see why PR should also be an
MR. We should just re-use MR for that and not duplicate code?
> ParallelReader should support getSequentialSubReaders if possible
> -----------------------------------------------------------------
>
> Key: LUCENE-2766
> URL: https://issues.apache.org/jira/browse/LUCENE-2766
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Andrzej Bialecki
> Attachments: LUCENE-2766.patch
>
>
> Applications that need to use ParallelReader can't currently use per-segment
> optimizations because getSequentialSubReaders returns null.
> Considering the strict requirements on input indexes that ParallelReader
> already enforces it's usually the case that the additional indexes are built
> with the knowledge of the primary index, in order to keep the docId-s
> synchronized. If that's the case then it's conceivable that these indexes
> could be created with the same number of segments, which in turn would mean
> that their docId-s are synchronized on a per-segment level. ParallelReader
> should detect such cases, and in getSequentialSubReader it should return an
> array of ParallelReader-s created from corresponding segments of input
> indexes.
--
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: [email protected]
For additional commands, e-mail: [email protected]
