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. </oops> 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." Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
