[Xapian-discuss] Is there a secondary sorting possible for relevance-sorts?

[Arjen van der Meijden]

On 16-11-2006 3:06 Olly Betts wrote:
> OK, here's a patch (also checked in to SVN).  I've done a quick set of
> tests to make sure all the changes work as intended, but let me know if
> anything doesn't seem right:

It appears as if the SORT=x SORTAFTER=1 combination uses relevance-bands 
or something like that?

For a simple query like 'pentium' there is one 100%-relevance hit which 
appears on top when doing docid=a, docid=d, 
sort=1+sortafter=1+sortreverse=1, but not when doing the 
sort=1+sortafter=1. Then the top-hit is "only" 99% and indeed a very old 
one.

1 is our value for topic-start-date. The result is consistent with a 
reverse sort on value 2 (which is the reverse of 1), so there is no bug 
I suppose.

The results using opposite docid-order seems to be much less distinct 
from the normal ordering than using the sort=-option.

But I think both will be worth a shot in our environment, just use 
descending docid-order by default. The differences in search time seems 
to be neglicable, compared to the ascending or "dont't care".

As an option, we can offer the user the option to do a rougher "order 
mostly by relevance, but display newer results first, even if its 
relevance is a bit lower". Like normal sorting its a bit slower 
(0.249393 for sortafter, 0.168958 for the same sort-value but leading) 
compared to not sorting (0.009417), in wall-clock-time it takes twice 
the amount of time though.

Best regards,

Arjen