[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662101#action_12662101
]
Michael McCandless commented on LUCENE-1476:
--------------------------------------------
{quote}
> If we move the deletions filtering up, then we'd increase traffic through
> that cache
{quote}
OK, right. So we may have some added cost because of this. I think
it's only TermScorer that uses the bulk API though.
{quote}
> If you were applying deletions filtering after Scorer.next(), then it seems
> likely that costs would go up because of extra hit processing. However, if
> you use Scorer.skipTo() to jump past deletions, as in the loop I provided
> above, then PhraseScorer etc. shouldn't incur any more costs themselves.
{quote}
Ahhh, now I got it! Good, you're right.
{quote}
> Under the skipTo() loop, I think the filter effectively does get applied
> earlier in the chain. Does that make sense?
{quote}
Right. This is how Lucene works today. Excellent.
So, net/net it seems like "deletes-as-a-filter" approach is compelling?
> 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: [email protected]
For additional commands, e-mail: [email protected]
