You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2018/07/23 17:33:00 UTC

[jira] [Commented] (SOLR-11733) add an option make json.facet refinement more "optimistic" like facet.field/facet.pivot so that long tail have a change to bubble up

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

Hoss Man commented on SOLR-11733:
---------------------------------

Linking SOLR-12343 where overrefine was added

> add an option make json.facet refinement more "optimistic" like facet.field/facet.pivot so that long tail have a change to bubble up
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-11733
>                 URL: https://issues.apache.org/jira/browse/SOLR-11733
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Facet Module
>            Reporter: Hoss Man
>            Priority: Major
>
> {{json.facet}} refinement is currently "pessimistic" by default.  Specifically: "Long Tail" terms that may not be in the "top n" on every shard, but are in the "top n + overrequest" for at least 1 shard aren't getting refined and included in the aggregated response in some cases.
> This is different then the "optimistic" approach taken in the existing {{facet.field}} and {{facet.pivot}} refinement, that refines all known terms whose counts *might* be high enough to put them in the topN based on what's known about the lowest count returned by each shard in phase #1.
> A mitigating option that people with particular concerns about long tail terms can consider is to set a "high" value for the {{overrefine}} parameter -- forcing Solr to refine more terms from phase#1 -- but this is somewhat of a "brute force" workaround, since it doesn't take into account any known info about the results of each shard from phase#1.
> This issue tracks possible improvements that could be made to the faceting code to be more sophisticated.
>  
> ----
> (NOTE: this Jira was originally filed as a bug report noting that {{json.facet}} refinement didn't seem to be working properly compared to facet.field refinement, and early comments are written in this mindset)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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