[
https://issues.apache.org/jira/browse/SOLR-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-7733:
---------------------------------
Attachment: SOLR-7733.patch
Here's a patch that removes the optimize info from the UI and adds some
warnings to the ref guide.
Yonik:
"Coupling" here means that I think de-emphasizing the optimize in the admin UI
makes more sense if we do it for the same release that addresses TMP since (I
hope) much of the reason to forceMerge will go away..
As far as the ref guide, I agree that optimize had other uses than controlling
deletes. I'm looking for some way to convey that the most reasonable
circumstance to consider optimizing is when the index is static, i.e. you can
run optimize every time you build your index (ok, that's overstating the case,
but you get the idea).
One problem is at present we give lots of guidance on _how_ to optimize but
very little on when it's a bad idea, or the consequences. How bad an idea will
depend in part on how the Lucene issue gets resolved.
If we respect the max segment size for forceMerge _and_ change forceMerge to
consider merging max sized docs with small segments even when they have > 50%
live docs then optimizing has a much smaller downside.
OTOH, if the resolution is to continue to create 1 segment and rewrite segments
with > X% deleted docs even if the result is > max segment size, optimize is
still pretty bad thing to do unless it can be done whenever the index changes.
Or at least regularly.
On the other other hand, it isn't clear to me that respecting the max segment
size on forceMerge results in as efficient on index as a single large segment...
I suppose that what we put in the ref guide will depend on how LUCENE-7976
eventually gets resolved.
> remove/rename "optimize" references in the UI.
> ----------------------------------------------
>
> Key: SOLR-7733
> URL: https://issues.apache.org/jira/browse/SOLR-7733
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
> Affects Versions: 5.3, 6.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: SOLR-7733.patch, SOLR-7733.patch
>
>
> Since optimizing indexes is kind of a special circumstance thing, what do we
> think about removing (or renaming) optimize-related stuff on the core admin
> and core overview pages? The "optimize" button is already gone from the core
> admin screen (was this intentional?).
> My personal feeling is that we should remove this entirely as it's too easy
> to think "Of course I want my index optimized" and "look, this screen says my
> index isn't optimized, that must mean I should optimize it".
> The core admin screen and the core overview page both have an "optimized"
> checkmark, I propose just removing it from the "overview" page and on the
> "core admin" page changing it to "Segment Count #". NOTE: the "overview" page
> already has a "Segment Count" entry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
