On Tue, Nov 30, 2010 at 8:24 AM, Martin Grotzke
<martin.grot...@googlemail.com> wrote:
> Still I'm wondering, why this issue does not occur with the plain
> example solr setup with 2 indexed docs. Any explanation?
It's an old option you have in your solrconfig.xml that causes a
different code path to be followed in Solr:
<!-- An optimization that attempts to use a filter to satisfy a search.
If the requested sort does not include score, then the filterCache
will be checked for a filter matching the query. If found, the filter
will be used as the source of document ids, and then the sort will be
applied to that. -->
<useFilterForSortedQuery>true</useFilterForSortedQuery>
Most apps would be better off commenting that out or setting it to
false. It only makes sense when a high number of queries will be
duplicated, but with different sorts.
>>
>> But: why is your app doing this? Ie, if numHits (rows) is 0, the only
>> useful thing you can get is totalHits?
>
> Actually I don't know this (yet). Normally our search logic should
> optimize this and ignore a requested sorting with rows=0, but there
> seems to be a case that circumvents this - still figuring out.
>
>>
>> Still I think we should fix it in Lucene -- it's a nuisance to push
>> such corner case checks up into the apps. I'll open an issue...
>
> Just for the record, this is https://issues.apache.org/jira/browse/LUCENE-2785
>
> One question: as leaving out sorting leads to better performance, this
> should also be true for rows=0. Or is lucene/solr already that clever
> that it makes this optimization (ignoring sort) automatically?
Solr has always special-cased this case and avoided sorting altogether
(for the normal code path... but overlooked it when
useFilterForSortedQuery=true.
-Yonik
http://www.lucidimagination.com
