[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654571#action_12654571
]
Michael McCandless commented on LUCENE-1476:
--------------------------------------------
I like this approach!!
It's also incremental in cost (cost of flush/commit is in proportion
to how many deletes were done), but you are storing the "packet" of
incremental deletes with the segment you just flushed and not against
the N segments that had deletes. And you write only one file to hold
all the tombstones, which for commit() (file sync) is much less cost.
And it's great that we don't need a new merge policy to handle all the
delete files.
Though one possible downside is, for a very large segment in a very
large index you will likely be merging (at search time) quite a few
delete packets. But, with the cutover to
deletes-accessed-only-by-iterator, this cost is probably not high
until a large pctg of the segment's docs are deleted, at which point
you should really expungeDeletes() or optimize() or optimize(int)
anyway.
If only we could write code as quickly as we can dream...
> 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]
