lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3141) Deprecate OPTIMIZE command in Solr
Date Sun, 19 Feb 2012 19:30:34 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211496#comment-13211496
] 

Yonik Seeley edited comment on SOLR-3141 at 2/19/12 7:28 PM:
-------------------------------------------------------------

bq.  Personally I feel the wiki text Yonik linked to is way too nice about this.

Here's the current wiki text (I just modified it to suggest what "infrequently" might mean...
i.e. nightly, not on the minute or something), added the term "very expensive" and bolded
the "entire" to draw attention to it.

{quote}
An optimize is like a hard commit except that it forces all of the index segments to be merged
into a single segment first. Depending on the use cases, this operation should be performed
infrequently (like nightly), if at all, since it is very expensive and involves reading and
re-writing the entire index. Segments are normally merged over time anyway (as determined
by the merge policy), and optimize just forces these merges to occur immediately.
{quote}

bq. I would agree to make a serious log.warn()

I'd be fine with that part.  I'll give it a shot.
                
      was (Author: yseeley@gmail.com):
    bq.  Personally I feel the wiki text Yonik linked to is way too nice about this.

Here's the current wiki text (I just modified it to suggest what "infrequently" might mean...
i.e. nightly, not on the minute or something), added the term "very expensive" and bolded
the "entire" to draw attention to it.

{code}
An optimize is like a hard commit except that it forces all of the index segments to be merged
into a single segment first. Depending on the use cases, this operation should be performed
infrequently (like nightly), if at all, since it is very expensive and involves reading and
re-writing the entire index. Segments are normally merged over time anyway (as determined
by the merge policy), and optimize just forces these merges to occur immediately.
{code}

bq. I would agree to make a serious log.warn()

I'd be fine with that part.  I'll give it a shot.
                  
> Deprecate OPTIMIZE command in Solr
> ----------------------------------
>
>                 Key: SOLR-3141
>                 URL: https://issues.apache.org/jira/browse/SOLR-3141
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message