-
From: Sean Timm [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 4:55 PM
To: java-dev@lucene.apache.org
Subject: Re: optimize() method call
In the brief test I did indexing 500K documents and optimizing every 10K
documents, I found that indexing is constant time (flat) and optimize
In the brief test I did indexing 500K documents and optimizing every 10K
documents, I found that indexing is constant time (flat) and optimize()
time increases linearly.
-Sean
Grant Ingersoll wrote on 4/18/2007, 4:29 PM:
> Has anyone done in benchmarking to approximate how long it takes to
>
Has anyone done in benchmarking to approximate how long it takes to
optimize different size indexes? Is the merging linear, sub-linear,
etc.?
On Apr 8, 2007, at 1:01 AM, Otis Gospodnetic wrote:
I'd advise against calling optimize() at all in an environment
whose indices are constantly upd
Robert Engels wrote:
I think this is great, and it gave me an idea. What if another thread could
call a "stop optimize" which would stop the optimize after it came to a
consistent state (not in the middle of a segment merge).
We schedule our optimizes for the "lull" time period, but with 24/7 op
Otis Gospodnetic wrote:
I'd advise against calling optimize() at all in an environment whose indices
are constantly updated.
+1
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECT
I'd advise against calling optimize() at all in an environment whose indices
are constantly updated. That's what mergeFactor helps with. Keep it low, and
Lucene itself will regularly merge segments more often. If one still wants to
call optimize(), you'd want to know how long it would take on
I think this is great, and it gave me an idea. What if another thread could
call a "stop optimize" which would stop the optimize after it came to a
consistent state (not in the middle of a segment merge).
We schedule our optimizes for the "lull" time period, but with 24/7 operation
this could b
