On 2010-04-15, Olly Betts wrote: > > I would be happy to have it called --sort=relevance too, the unsorted > > points out potential performance improvements a bit better, IMHO > > (although they seem to be really small with a warm cache). > > When using the results of a search to add/remove tags, there's likely to be > an additional win from --sort=unsorted as documents will now be processed > in docid order which will tend to have a more cache friendly locality of > access.
Olly was right in that even for "notmuch tag" we were sorting the results by date before applying tag changes. I have slightly reworked my patch to have notmuch tag avoid doing that. I also split up the patch in 3 patches that do one thing each. The patches do: 1: Introduce NOTMUCH_SORT_UNSORTED 2: Introduce notmuch search --sort=unsorted 3: Make notmuch tag not sort results by date #2 is the one I am least sure about, I don't know if there is a use case for notmuch search returning unsorted results. But 1 & 3 are useful at least. > Also, sorting by relevance requires more calculations and may require fetching > additional data (document length for example). > > So I think it would make sense for --sort=relevance and --sort=unsorted to be > separate options. Now I am a bit confused. The API docs state that sort_by_relevance is the default. So by skipping any sort_by_value() will that incur the additional calculations (with our BoolWeight set?). All I want is the fasted way to return a searched set of docs :-). Patches 1-3 follow as reply to this one Sebastian _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch