I like that name! That's a good way to think of it, assuming the
available coins/bill denominations grow exponentially with a base
roughly of mergeFactor :)
It's also like the odometer on a car.
Mike
On Tue, Apr 6, 2010 at 10:51 PM, Lance Norskog wrote:
> Ok, thanks. I'm studying the RAM buffe
Ok, thanks. I'm studying the RAM buffer/MergePolicy nexus as we speak.
I hereby name the function "minimum number of coins and bills needed
to represent a number" as its "change log".
On Tue, Apr 6, 2010 at 2:08 AM, Michael McCandless
wrote:
> Actually this isn't quite right.
>
> Lucene flushes
Actually this isn't quite right.
Lucene flushes a new segment whenever RAM is full (not every 5 docs if
mergeFactor is 5).
Whereas mergeFactor decides how many segments of roughly the same size
are merged at once.
So eg if you index 42 docs, unless the docs are immense (or, are not
indexed in a
mergeFactor=5 means that if there are 42 documents, there will be 3 index files:
1 with 25 documents,
3 with 5 documents, and
1 with 2 documents
Imagine making change with coins of 1 document, 5 documents, 5^2
documents, 5^3 documents, etc.
On Mon, Apr 5, 2010 at 10:59 AM, Chris Hostetter
wrote
I'm guessing the user is expecting there to be one cfs file for the
index, and does not understand that its actually per segment.
On 04/05/2010 01:59 PM, Chris Hostetter wrote:
This sounds completley normal form what i remembe about mergeFactor.
Segmenets are merged "by level" meaning that wit
This sounds completley normal form what i remembe about mergeFactor.
Segmenets are merged "by level" meaning that with a mergeFactor of 5, once
5 "level 1" segments are formed they are merged into a single "level 2"
segment. then 5 more "level 1" segments are allowed to form before the
next m
/no-of-cfs-files-are-more-that-the-mergeFactor-tp520093p520093.html
Sent from the Solr - User mailing list archive at Nabble.com.
