lucene-dev mailing list archives

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


Uwe Schindler commented on SOLR-3141:

100 segments?

In comparison the numbers for Lucene 2.9 lowered extensively, pre-2.9 optimizing was often
a must, I agree! The problem was Multi* with itsself having priority-queue like structures
slowing down term enumeration and postings rerieval. With Lucene 3.x the difference between
an optimized and a "standard 8 segment index" was always below measurement uncertainity (see
lots of benchmarks from Mike on Lucene 4). For standard relevance-ranked or numerics sorting
there was never a real slowdown.

I am always talking about relevance-ranked results and numerics. With StringIndex sorting
there is certainly an overhead, but as we support sortMissingLast now also for numerics, almost
nobody has to use it.
> 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