[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661977#action_12661977
]
Marvin Humphrey commented on LUCENE-1476:
-----------------------------------------
Paul Elschot:
> How about a SegmentSearcher?
I like the idea of a SegmentSearcher in general. A little while back, I
wondered whether exposing SegmentReaders was really the best way to handle
segment-centric search. Upon reflection, I think it is. Segments are a good
unit. They're pure inverted indexes (notwithstanding doc stores and
tombstones); the larger composite only masquerades as one.
I noticed that in one version of the patch for segment-centric search
(LUCENE-1483), each sorted search involved the creation of sub-searchers, which
were then used to compile Scorers. It would make sense to cache those as
individual SegmentSearcher objects, no?
And then, to respond to the original suggestion, the SegmentSearcher level
seems like a good place to handle application of a deletions quasi-filter. I
think we could avoid having to deal with segment-start offsets that way.
> BitVector implement DocIdSet
> ----------------------------
>
> Key: LUCENE-1476
> URL: https://issues.apache.org/jira/browse/LUCENE-1476
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.4
> Reporter: Jason Rutherglen
> Priority: Trivial
> Attachments: LUCENE-1476.patch
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> BitVector can implement DocIdSet. This is for making
> SegmentReader.deletedDocs pluggable.
--
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
