[
https://issues.apache.org/jira/browse/SOLR-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130096#comment-15130096
]
Shai Erera commented on SOLR-5730:
----------------------------------
Hi [~jkrupan], your understanding is correct.
bq. The third ticket has some user impact and delivers some additional minor
benefits
It depends how you view it. I recently found that defining my own MP (when it
wraps another one especially) is not so trivial in {{solrconfig.xml}}. You
could argue that for the majority of the users, this is a very advanced feature
to have, and I would agree. But for those who want to write more advanced and
_tailored_ merge policies, SOLR-8621 will allow them to do so quite easily. And
the impact to the users who don't need it is marginal (see my previous comment).
The reason I quoted that sentence is because of the words _minor benefits_ --
it's a matter of perspective of course -- if you will be facing the need to
write a special MP, then this feature will have huge benefits for you. I know
you don't argue about the need, but just wanted to give my own perspective on
this.
As for {{UpgradeIndexMergePolicy}} you're right that it's a one-time operation
and the main purpose is to allow you to upgrade all segments of your index to a
newer format. You will likely only use it when you upgrade to 6.0 and you think
(or know) that you still have segments created by 4.x code. Note, that that you
upgraded your software to Solr 5.x doesn't mean that the existing indexes'
segments were upgraded too!
But even for this one-time operation, you currently have no way to define
{{UpgradeIndexMergePolicy}} in a {{<mergePolicy>}} element, since it needs to
take a wrapped MP which will actually decide which segments to merge together
etc. (i.e. create the merge plan). So even for this one time operation, you'd
need to have SOLR-8621 in place.
I don't view SOLR-4654 as an umbrella ticket at all, but more of a duplicate of
this one. SOLR-8621 lays the foundations for allowing users to define compound
merge policies, and in this ticket we will add a {{SortingMergePolicyFactory}}.
As you said, this only handles the indexing side of things, and there's still
work to be done in order to make use of it during search (i.e. integrate
{{EarlyTerminatingSortingCollector}}. Also, I'm pretty sure I saw in
{{SolrIndexSearcher}} early termination by time (which sort of covers the
second part of SOLR-4654), though I haven't seen it actually being used.
> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector
> configurable in Solr
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
> Issue Type: New Feature
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch,
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached
> patch:*
> {noformat}
> <sortMerges enable="true">
> <str name="sort">timestamp desc</str>
> </sortMerges>
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -<mergePolicy class="TieredMergePolicy"/>
> +<mergePolicyFactory class="SortingMergePolicyFactory">
> + <str name="in">TieredMergePolicyFactory</str>
> + <str name="sort">timestamp desc</str>
> +</mergePolicyFactory>
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> &sort=timestamp+desc&segmentTerminateEarly=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
