If you use sort, you are basically ignoring relevancy (unless you put that into sort). Which you seem to know as your example uses FQ.
Do you see performance drop on non-clustered or clustered Solr? Because, I would not be surprised if, for clustered node, all the results need to be brought into one place to sort even if only 10 (of say 100) would be sent back, where without sort, each node is asked for their "top X" matches and others are never even sent. That would be my working theory anyway, I am not deep into milti-path mode the cluster code does. Regards, Alex. On Mon, 11 May 2020 at 15:16, Stephen Lewis Bianamara <stephen.bianam...@gmail.com> wrote: > > Hi SOLR Community, > > What is the order of operations which SOLR applies to sorting? I've > observed many times and across SOLR versions that a restrictive filter with > a sort takes an extremely long time to return, suggesting to me that the > SORT is applied before the filter. > > An example situation is querying for fq:Foo=Bar vs querying for fq:Foo=Bar > sort by Id desc. I've observed over many SOLR versions and collections that > the former is orders of magnitude cheaper and quicker to respond, even when > the result set is tiny (10-100). > > Does anyone in this forum know whether this is the default behavior and > whether there is any way through the API or SOLR configuration to apply > sorts after filters? > > Thanks, > Stephen
