lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: IndexWriter.optimize and memory usage
Date Fri, 03 Dec 2004 21:01:57 GMT
On Friday 03 December 2004 08:43, Paul Elschot wrote:
> On Friday 03 December 2004 07:50, Chris Hostetter wrote:
> > So, If I'm understanding you (and the javadocs) correctly, the real key
> > here is maxMergeDocs.  It seems like addDocument will never merge a
> > segment untill maxMergeDocs have been added? ... meaning that I need a
> > value less then the default (Integer.MAX_VALUE) if I want IndexWriter to
> > do incrimental merges as I go ...
> > 
> >     ...except...
> > 
> > ...if that were the case, then exactly is the meaning of mergeFactor?

<oops correction="minMergeDocs should be replaced by mergeFactor:">

> maxMergeDocs controls the sizes of the intermediate segments
> when adding documents.
> With maxMergeDocs at default, adding a document can take as much time as
: (and have the same effect as) optimize.  Eg. with mergeFactor at 10, the
> 1000'th added document will create a segment of size 1000.
> With maxMergeDocs at a lower value than 1000, the last merge (of the 10
> segments with 100 docs each) will not be done.
: optimize() uses mergeFactor for its final merges, but it ignores
> maxMergeDocs. 


Meanwhile these fields have been deprecated in the development
version for set... methods.
Setting minMergeDocs is is deprecated and to be replaced by
setMaxBufferedDocs(). The javadoc for this reads:

"Determines the minimal number of documents required before the buffered 
in-memory documents are merging and a new Segment is created. Since Documents 
are merged in a RAMDirectory, large value gives faster indexing. At the same 
time, mergeFactor limits the number of files open in a FSDirectory."

Paul Elschot

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message