--- /dev/null
+Return-Path: <MarkR.Andersom@amd.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 4844E431FBC\r
+ for <notmuch@notmuchmail.org>; Wed, 23 Dec 2009 10:19:40 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 67vad1gYrklh for <notmuch@notmuchmail.org>;\r
+ Wed, 23 Dec 2009 10:19:38 -0800 (PST)\r
+Received: from VA3EHSOBE006.bigfish.com (va3ehsobe005.messaging.microsoft.com\r
+ [216.32.180.15])\r
+ by olra.theworths.org (Postfix) with ESMTP id 1F53D431FAE\r
+ for <notmuch@notmuchmail.org>; Wed, 23 Dec 2009 10:19:38 -0800 (PST)\r
+Received: from mail164-va3-R.bigfish.com (10.7.14.239) by\r
+ VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id\r
+ 8.1.240.5; Wed, 23 Dec 2009 18:19:37 +0000\r
+Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by\r
+ mail164-va3-R.bigfish.com (Postfix) with ESMTP id 0C7981990649;\r
+ Wed, 23 Dec 2009 18:19:37 +0000 (UTC)\r
+X-SpamScore: -20\r
+X-BigFish: VPS-20(zz1418M1432R98dNzz1202hzzz32i6bh61h)\r
+X-Spam-TCS-SCL: 0:0\r
+Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by mail164-va3\r
+ (MessageSwitch) id 1261592374181609_14289;\r
+ Wed, 23 Dec 2009 18:19:34 +0000 (UTC)\r
+Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.249]) by\r
+ mail164-va3.bigfish.com (Postfix) with ESMTP id 217D9174807C;\r
+ Wed, 23 Dec 2009 18:18:57 +0000 (UTC)\r
+Received: from ausb3extmailp02.amd.com (163.181.251.22) by\r
+ VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS)\r
+ id 14.0.482.32; Wed, 23 Dec 2009 18:18:54 +0000\r
+Received: from ausb3twp02.amd.com ([163.181.250.38]) by\r
+ ausb3extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id\r
+ nBNIIoEn030592; Wed, 23 Dec 2009 12:18:54 -0600\r
+X-WSS-ID: 0KV4AV8-02-CLS-02\r
+X-M-MSG: \r
+Received: from sausexbh2.amd.com (SAUSEXBH2.amd.com [163.181.22.102]) by\r
+ ausb3twp02.amd.com (Tumbleweed MailGate 3.7.2) with ESMTP id\r
+ 2FF36FCC3B2; Wed, 23 Dec 2009 12:18:44 -0600 (CST)\r
+Received: from sausexmb4.amd.com ([163.181.3.15]) by sausexbh2.amd.com with\r
+ Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 12:18:49 -0600\r
+Received: from optimon.amd.com ([163.181.34.104]) by sausexmb4.amd.com with\r
+ Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 12:18:48 -0600\r
+Received: from mhdc-ns01.amd.com (mhdc-ns01.amd.com [165.204.35.147]) by\r
+ optimon.amd.com (8.12.10/8.12.10) with ESMTP id nBNIImCG032389;\r
+ Wed, 23 Dec 2009 12:18:48 -0600\r
+Received: from testarossa.amd.com (testarossa.amd.com [165.204.147.44]) by\r
+ mhdc-ns01.amd.com (8.13.8+Sun/8.13.8) with ESMTP id nBNIImru028811;\r
+ Wed, 23 Dec 2009 11:18:48 -0700 (MST)\r
+Received: (from manderso@localhost) by testarossa.amd.com\r
+ (8.13.1/8.13.1/Submit) id nBNIIjrK026982;\r
+ Wed, 23 Dec 2009 11:18:45 -0700\r
+X-Authentication-Warning: testarossa.amd.com: manderso set sender to\r
+ MarkR.Andersom@amd.com using -f\r
+From: Mark Anderson <MarkR.Anderson@amd.com>\r
+To: Olly Betts <olly@survex.com>, notmuch@notmuchmail.org\r
+In-Reply-To: <loom.20091223T043223-941@post.gmane.org>\r
+References: <3wdskb8oh77.fsf@testarossa.amd.com>\r
+ <87hbroyyf6.fsf@yoom.home.cworth.org>\r
+ <loom.20091223T043223-941@post.gmane.org>\r
+Date: Wed, 23 Dec 2009 11:18:45 -0700\r
+Message-ID: <3wd637xo8oq.fsf@testarossa.amd.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset="us-ascii"\r
+X-OriginalArrivalTime: 23 Dec 2009 18:18:48.0730 (UTC)\r
+ FILETIME=[5F4C17A0:01CA83FC]\r
+X-Reverse-DNS: ausb3extmailp02.amd.com\r
+Subject: Re: [notmuch] Rather simple optimization for notmuch tag\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.12\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 23 Dec 2009 18:19:40 -0000\r
+\r
+On Wed, 23 Dec 2009 03:45:14 +0000, Olly Betts <olly@survex.com> wrote:\r
+> Carl Worth writes:\r
+> > On Fri, 18 Dec 2009 00:49:00 -0700, Mark Anderson wrote:\r
+> > > I was updating my poll script that tags messages, and a common idiom is\r
+> > > to put\r
+> > > tag +mytag <search_terms> and not tag:mytag\r
+> > > \r
+> > > I don't know anything about efficiency, but for the simple single-tag\r
+> > > case, couldn't we imply the "and not tag:mytag" from the +mytag action\r
+> > > list for the tag command?\r
+> > \r
+> > On one level, it really shouldn't be a performance issue to tag messages\r
+> > that already have a particular tag. (And in fact, the recently proposed\r
+> > patches to fix Xapian defect 250 even address this I think.)\r
+> \r
+> Applying a filter up-front like this is likely to still help I think as it\r
+> avoids Xapian having to reverse-engineer this information internally.\r
+\r
+That's good to hear.\r
+\r
+> Actually, you could do this with multiple tags - you just need to build\r
+> a filter for documents which might be affected.\r
+> \r
+> So if you're adding tags a1 and a2, you want: <query> AND_NOT (a1 AND a2)\r
+> since documents which already have tags a1 and a2 can be ignored.\r
+> \r
+> If you're removing d1 and d2, then the filter is: <query> AND (d1 OR d2)\r
+> since documents have to be tagged d1 or d2 in order for the removal to\r
+> do anything.\r
+> \r
+> Handling a combination of removals and additions is trickier, but probably\r
+> possible, although the more tags you are dealing with, the less profitable\r
+> the filtering is likely to be (as the filter is likely to cull fewer\r
+> documents yet be more expensive to evaluate).\r
+\r
+But the transform is pretty simple, I think that any combination of\r
+additions and removals could be transformed according to the following\r
+formula.\r
+\r
+notmuch tag +a1 +a2 +a3 -d1 -d2 -d3 <search-terms>\r
+\r
+would transform to something like:\r
+\r
+<search-terms> and ( not(a1) or not(a2) or not(a3) or d1 or d2 or d3) \r
+\r
+There are certainly may be much more optimal ways to do it depending on\r
+the specific corpus of the database, considering if the tags a1 and a2\r
+and a3 are usually added as one tag, or if the addition is done\r
+individually, because if I know that a3 implies a1 and a2, the first 3\r
+terms could be combined to not(a1 and a2 and a3), or I could just\r
+exclude a3 tagged messages for nearly the same effect, with expected\r
+performance improvements.\r
+\r
+Unfortunately this requires that I know more about how the tags are used\r
+than I ever want notmuch to deal with. Perhaps a follow-on or parallel\r
+project with less emphasis on minimalism.\r
+\r
+\r
+This looks pretty good to me. Easy to implement and not likely to break\r
+things. I've been wondering about whether there should be a repository\r
+of mail added to the notmuch git so that we can start testing these\r
+kinds of features on a consistent body of mail.\r
+ \r
+I doubt that I'll be the one to write this, since I don't have any time\r
+set aside for real coding, but if it takes long enough, I'll probably\r
+pick this one up eventually.\r
+\r
+-Mark\r
+\r
projects / notmuch-archives.git / commitdiff