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

Uwe Schindler commented on LUCENE-1960:
---------------------------------------

I do not know if this is a bug in 2.9.0, but it seems that segments with all 
documents deleted are not automatically removed:

{code}
2009-10-24 17:08:15,264 INFO org.apache.lucene.index.CheckIndex -   4 of 14: 
name=_dlo docCount=5
2009-10-24 17:08:15,264 INFO org.apache.lucene.index.CheckIndex -     
compound=true
2009-10-24 17:08:15,264 INFO org.apache.lucene.index.CheckIndex -     
hasProx=true
2009-10-24 17:08:15,264 INFO org.apache.lucene.index.CheckIndex -     numFiles=2
2009-10-24 17:08:15,265 INFO org.apache.lucene.index.CheckIndex -     size 
(MB)=0.059
2009-10-24 17:08:15,265 INFO org.apache.lucene.index.CheckIndex -     
diagnostics = {java.version=1.5.0_21, lucene.version=2.9.0 817268P - 2009-09-21 
10:25:09, os=SunOS, os.arch=amd64, java.vendor=Sun Microsystems Inc., 
os.version=5.10, source=flush}
2009-10-24 17:08:15,265 INFO org.apache.lucene.index.CheckIndex -     has 
deletions [delFileName=_dlo_1.del]
2009-10-24 17:08:15,356 INFO org.apache.lucene.index.CheckIndex -     test: 
open reader.........OK [5 deleted docs]
2009-10-24 17:08:15,356 INFO org.apache.lucene.index.CheckIndex -     test: 
fields..............OK [136 fields]
2009-10-24 17:08:15,357 INFO org.apache.lucene.index.CheckIndex -     test: 
field norms.........OK [136 fields]
2009-10-24 17:08:15,372 INFO org.apache.lucene.index.CheckIndex -     test: 
terms, freq, prox...OK [1698 terms; 4236 terms/docs pairs; 0 tokens]
2009-10-24 17:08:15,373 INFO org.apache.lucene.index.CheckIndex -     test: 
stored fields.......OK [0 total field count; avg ? fields per doc]
2009-10-24 17:08:15,373 INFO org.apache.lucene.index.CheckIndex -     test: 
term vectors........OK [0 total vector count; avg ? term/freq vector fields per 
doc]
{code}

Shouldn't such segments not be removed automatically during the next merge?

But this would be another issue. In my opinion, we are fine with the current 
approach, the longer optimization time is rectified by the larger index size 
because of no compression anymore and the more heavyer initial merge without 
addRawDocument is only 30% slower (one time!).

+1 for committing

> Remove deprecated Field.Store.COMPRESS
> --------------------------------------
>
>                 Key: LUCENE-1960
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1960
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Michael Busch
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 3.0
>
>         Attachments: lucene-1960-1.patch, lucene-1960-1.patch, 
> lucene-1960.patch, optimize-time.txt
>
>
> Also remove FieldForMerge and related code.

-- 
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