[
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 [[email protected]] – 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: [email protected]
For additional commands, e-mail: [email protected]
