[
https://issues.apache.org/jira/browse/SOLR-12839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649265#comment-16649265
]
Hoss Man commented on SOLR-12839:
---------------------------------
{quote}We should perhaps think about how to extend to N sorts instead of 2.
{quote}
I'm confused ... why/how/when would it make sense to resort multiple times? Do
you have an example of what you have in mind?
My usecase/idea here is directly analogous to the "rerank" concept of queries
and sorting (docs) by score: start with a "simple" query/sort when doing the
first pass to find matches/buckets, then "rerank/resort only the topN on a more
complex query/function that you don't want to compute against every doc/bucket.
I can't really think of a situation where it would would be useful to resort
buckets more then once – or how it could work practically given the 2 phrase
nature of distributed facet refinement. (as long as we only do 2 phrases, it
seems like it would just be wasted cycles to do anything but the first and last
sort?)
{quote}Maybe just append a number to our existing sort syntax, so we would get
something like "foo desc, bar asc 50" (bar would be a tiebreak in this case)
{quote}
I'm not really understanding what you're suggestion ... can you elaborate on
what would happen in that example? if "foo desc" is the primary sort, and "bar
asc" is the tiebreaker, then what is being resorted on? and where does the "50"
in your example come into play,? (is that suppose to be how many of the top
buckets we want to resort? the rerank parser has a {{reRankDocs}} local param
but i didn't really see much point in having that concept for facet resorting
since the shards will have already computed all the stat values for all the
buckets once they've been refined, and so why bother artificially limiting the
number of buckets being considered for resorting beyond that?)
{quote}Also keeping in mind that sort should be able to have tiebreaks someday.
{quote}
...
{quote}Or given that this is just an extension of the sort syntax, it could
even just go in the "sort" param itself and not bother with "resort"
{quote}
I briefly considered adding resorting as a new option to the sort syntax, but
quickly dismissed it for the precise reason that you mention: i expect the sort
option to get more robust, and supporting secondary, tertiary, etc... tie
breakers - so trying to shoe horn resorting into it as well seemed like a bad
idea (plus i wanted to ensure that whatever features were added to the sort
syntax down the road – tie breakers, etc... – would also be supported for
resorting as well.)
> 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
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
