lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3141) Deprecate OPTIMIZE command in Solr
Date Sun, 19 Feb 2012 17:16:38 GMT


Yonik Seeley commented on SOLR-3141:

bq. I am always talking about relevance-ranked results and numerics.

And those are often not the bottleneck for Solr users.

There are a few issues here:
- the queries we often see in the field can be vastly more complex than the standard ones
that lucene tests with
- people are often most concerned with their slowest queries, not their average query speed
(as long as they can meet throughput needs)
- full-text search is often not the bottleneck at all 

Another issue that I've seen a couple of customers hit: big memory increases in the field
cache as the number of segments grows.  The string index values are not shared per-segment,
and hence in the worst case, 2 times the number of segments equals almost 2 times the memory
for the per-segment FieldCache entries.

There are tradeoffs to a lot of these things, and we should be careful to not fall into a
"one size fits all" mentality.
> Deprecate OPTIMIZE command in Solr
> ----------------------------------
>                 Key: SOLR-3141
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 3.5
>            Reporter: Jan H√łydahl
>              Labels: force, optimize
>             Fix For: 3.6
> Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that issue first.
> Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, what should
be done with Solr's ancient optimize command?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message