[jira] [Commented] (SOLR-12839) add a 'resort' option to JSON faceting

["Hoss Man (JIRA)" <ji...@apache.org>]

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

Hoss Man commented on SOLR-12839:
---------------------------------

Pinging [~yseeley@gmail.com] – any thoughts/objections to the idea i mentioned on Oct 22 ...
{quote}... maybe the best way to more forward _now_ with a short term improvement for the sorting/resorting on an {{expensive_function()}} vs {{cheaper_aproximation_of_expensive_function()}} performance hint/optimization – in a way that wouldn't hinder us down the road with more full featured bucket processing – would be to "invert" the API i proposed/implemented and renamed the option...
 * instead of adding a {{resort}} option, add an {{approximate_sort}} option and flip the meaning from what i was originally thinking...
{noformat}
json.facet={
  categories : {
    type : terms,
    field : cat,
    limit : 5,
    sort : "consumer_value desc",
    approximate_sort : "count desc",
    facet : { consumer_value : "sum(div(popularity,price))" }
  }
}
{noformat}

 * instead of using {{sort}} in phase#1, and resorting on the {{resort}} option after merging, we would use {{approximate_sort}} in phase#1, and {{sort}} in phase#2
 * from an end user perspective {{sort}} is the most important thing:
 ** the buckets to be returned will be in {{sort}} order
 ** {{approximate_sort}} is an expert level option only used as an inexpensive approximation when picking the buckets to be returned, where the exact number of buckets considered in this way is essentially an implementation detail
 * down the road, when we add "tiebreaker" support to "sort type options", it should be fairly trivial to support it for both options (with some generalization of the helper methods added in the patch)
 * farther down the road, if we want a more robust "sort, resort, process, filter the buckets returned" type option/syntax to replace the {{sort}} param – then we can add that independent of the {{approximate_sort}} option, and {{approximate_sort}} can still be used as a way to indicate an "inexpensive" way to initially rank the buckets to consider before any of that new functionality.{quote}
...this would be a fairly meaty re-working of the existing patch i've got in progress (sort->approx_sort, resort->sort, & flipping the syntax in all the test queries) so i'd rather not bite it off if it's something you have objections to in principle.

> add a 'resort' option to JSON faceting
> --------------------------------------
>
>                 Key: SOLR-12839
>                 URL: https://issues.apache.org/jira/browse/SOLR-12839
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Facet Module
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>            Priority: Major
>         Attachments: SOLR-12839.patch, SOLR-12839.patch, SOLR-12839.patch
>
>
> As discusssed in SOLR-9480 ...
> bq. Similar to how the {{rerank}} request param allows people to collect & score documents using a "cheap" query, and then re-score the top N using a ore expensive query, I think it would be handy if JSON Facets supported a {{resort}} option that could be used on any FacetRequestSorted instance right along side the {{sort}} param, using the same JSON syntax, so that clients could have Solr internaly sort all the facet buckets by something simple (like count) and then "Re-Sort" the top N=limit (or maybe ( N=limit+overrequest ?) using a more expensive function like skg()



--
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