Return-Path: <gmn-notmuch@m.gmane.org>
X-Original-To: notmuch@notmuchmail.org
Delivered-To: notmuch@notmuchmail.org
Received: from localhost (localhost [127.0.0.1])
	by olra.theworths.org (Postfix) with ESMTP id 94257431FBC
	for <notmuch@notmuchmail.org>; Tue, 22 Dec 2009 19:45:45 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
Received: from olra.theworths.org ([127.0.0.1])
	by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id gW75KLRAELZG for <notmuch@notmuchmail.org>;
	Tue, 22 Dec 2009 19:45:44 -0800 (PST)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
	by olra.theworths.org (Postfix) with ESMTP id 5D3BC431FAE
	for <notmuch@notmuchmail.org>; Tue, 22 Dec 2009 19:45:44 -0800 (PST)
Received: from list by lo.gmane.org with local (Exim 4.50) id 1NNIAQ-0000KN-4t
	for notmuch@notmuchmail.org; Wed, 23 Dec 2009 04:45:42 +0100
Received: from ip-118-90-130-94.xdsl.xnet.co.nz ([118.90.130.94])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <notmuch@notmuchmail.org>; Wed, 23 Dec 2009 04:45:37 +0100
Received: from olly by ip-118-90-130-94.xdsl.xnet.co.nz with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <notmuch@notmuchmail.org>; Wed, 23 Dec 2009 04:45:37 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: notmuch@notmuchmail.org
From: Olly Betts <olly@survex.com>
Date: Wed, 23 Dec 2009 03:45:14 +0000 (UTC)
Lines: 39
Message-ID: <loom.20091223T043223-941@post.gmane.org>
References: <3wdskb8oh77.fsf@testarossa.amd.com>
	<87hbroyyf6.fsf@yoom.home.cworth.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 118.90.130.94 (Mozilla/5.0 (X11; U; Linux x86_64; en-GB;
	rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6)
Sender: news <news@ger.gmane.org>
Subject: Re: [notmuch] Rather simple optimization for notmuch tag
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Use and development of the notmuch mail system."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2009 03:45:45 -0000

Carl Worth writes:
> On Fri, 18 Dec 2009 00:49:00 -0700, Mark Anderson wrote:
> > I was updating my poll script that tags messages, and a common idiom is
> > to put
> >  tag +mytag <search_terms> and not tag:mytag
> > 
> > I don't know anything about efficiency, but for the simple single-tag
> > case, couldn't we imply the "and not tag:mytag" from the +mytag action
> > list for the tag command?
> 
> On one level, it really shouldn't be a performance issue to tag messages
> that already have a particular tag. (And in fact, the recently proposed
> patches to fix Xapian defect 250 even address this I think.)

Applying a filter up-front like this is likely to still help I think as it
avoids Xapian having to reverse-engineer this information internally.

> One potential snag with both ideas is that the "notmuch tag"
> command-line as currently implemented allows for multiple tag additions
> and removals with a single search. So the optimization here couldn't be
> used unless there was just a single tag action.

Actually, you could do this with multiple tags - you just need to build
a filter for documents which might be affected.

So if you're adding tags a1 and a2, you want: <query> AND_NOT (a1 AND a2)
since documents which already have tags a1 and a2 can be ignored.

If you're removing d1 and d2, then the filter is: <query> AND (d1 OR d2)
since documents have to be tagged d1 or d2 in order for the removal to
do anything.

Handling a combination of removals and additions is trickier, but probably
possible, although the more tags you are dealing with, the less profitable
the filtering is likely to be (as the filter is likely to cull fewer
documents yet be more expensive to evaluate).

Cheers,
    Olly