From: "Sebastian Spaeth" <Sebastian@SSpaeth.de>
To: Olly Betts <olly@survex.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH] allow to not sort the search results
In-Reply-To: <loom.20100415T144148-25@post.gmane.org>
References: <1271226655-5672-1-git-send-email-Sebastian@SSpaeth.de>
	<20100414065525.GA11770@jdc.jasonjgw.net>
	<87hbnebhg0.fsf@SSpaeth.de>
	<loom.20100415T144148-25@post.gmane.org>
Date: Fri, 16 Apr 2010 08:37:04 +0200
Message-ID: <87eiifj433.fsf@SSpaeth.de>
User-Agent: notmuch version 0.1-167-g21df013 (Emacs
 23.1.1/x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

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