"*:*" is a constant score query - every document has the same score, so the
concept of relevancy has no relevance.
But, in theory, you could apply boost queries and function queries to scale
or offset those constant scores. If so, then you should see relevancy
sorting, otherwise the concept of relevancy does not apply.
I don't think Solr offers any "contract" as to ordering of constant score
documents or merging of same score documents across shards. At least I have
never seen such a contract published. So, if you are merely observing the
actual behavior of Solr, fine, but if you are expecting that such behavior
will persist in future releases, there can be no such guarantee.
I don't think Solr will necessarily guarantee that Lucene doc IDs will be
the same between replicas (the order in which distributed updates are
received), so there is no guarantee that behavior you see from one
round-robin iteration will necessarily be the same on a repeat of the same
distributed query.
The bottom line is: What exactly are you after, simply an explanation for
what you are seeing, or a guarantee that you will always see that behavior?
-- Jack Krupansky
-----Original Message-----
From: Michael Sokolov
Sent: Monday, September 02, 2013 7:42 PM
To: solr-user@lucene.apache.org
Subject: distributed query result order tie break question
My question is about how query results are ordered in a distributed
query when sorting by "relevance" and all the documents have the same
score, for example, when querying for "*:*".
It looks to me as if score ties are broken by shard and then within each
shard, by docid. So for example, if I were to iterate over all the
documents using such a query, I would expect to get all the documents
from one shard first, then all the documents from another shard, etc.
Is that right?
Thanks
-Mike Sokolov
