From 7c15030a6a2730590d5676c0b0fcb3970373a128 Mon Sep 17 00:00:00 2001 From: Jameson Graef Rollins Date: Tue, 10 Jul 2012 08:55:29 +1700 Subject: [PATCH] Re: query on a subset of messages ? --- 45/12ee2f136bd0b87c65e876cfc1565025314bcc | 129 ++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 45/12ee2f136bd0b87c65e876cfc1565025314bcc diff --git a/45/12ee2f136bd0b87c65e876cfc1565025314bcc b/45/12ee2f136bd0b87c65e876cfc1565025314bcc new file mode 100644 index 000000000..e0f1ce900 --- /dev/null +++ b/45/12ee2f136bd0b87c65e876cfc1565025314bcc @@ -0,0 +1,129 @@ +Return-Path: +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 1311A431FBD + for ; Mon, 9 Jul 2012 08:55:49 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.29 +X-Spam-Level: +X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled +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 xJIPSg+O6NNx for ; + Mon, 9 Jul 2012 08:55:46 -0700 (PDT) +Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu + [131.215.239.19]) + by olra.theworths.org (Postfix) with ESMTP id BFCE7431FAE + for ; Mon, 9 Jul 2012 08:55:46 -0700 (PDT) +Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1]) + by earth-doxen-postvirus (Postfix) with ESMTP id 5B34266E00D1; + Mon, 9 Jul 2012 08:55:44 -0700 (PDT) +X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new +Received: from finestructure.net (unknown [76.89.192.57]) + (Authenticated sender: jrollins) + by earth-doxen-submit (Postfix) with ESMTP id 5FA9166E00AE; + Mon, 9 Jul 2012 08:55:32 -0700 (PDT) +Received: by finestructure.net (Postfix, from userid 1000) + id ECC6C378; Mon, 9 Jul 2012 08:55:31 -0700 (PDT) +From: Jameson Graef Rollins +To: Sebastien Binet , + Notmuch developer list +Subject: Re: query on a subset of messages ? +In-Reply-To: <871ukl5oj7.fsf@cern.ch> +References: <871ukl5oj7.fsf@cern.ch> +User-Agent: Notmuch/0.13.2+54~ga0426dc (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Mon, 09 Jul 2012 08:55:29 -0700 +Message-ID: <87ehol2aku.fsf@servo.finestructure.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha256; protocol="application/pgp-signature" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 09 Jul 2012 15:55:49 -0000 + +--=-=-= + +On Mon, Jul 09 2012, Sebastien Binet wrote: +> I was trying to reduce the I/O stress during my usual email +> fetching+tagging by writing a little program using the go bindings to +> notmuch. +> +> ie: +> db, status := notmuch.OpenDatabase(db_path, +> notmuch.DATABASE_MODE_READ_WRITE) +> query := db.CreateQuery("(tag:new AND tag:inbox)") +> msgs := query.SearchMessages() +> for _,msg := range msgs { +> tag_msg(msg, tagqueries) +> } +> +> +> where tagqueries is a subquery of the form: +> [ +> { +> "Cmd": "+to-me", +> "Query": "(to:sebastien.binet@cern.ch and not tag:to-me)" +> }, +> { +> "Cmd": "+sci-notmuch", +> "Query": "from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org or subject:notmuch" +> } +> ] + + +Hi, Sebastian. It's really hard for me to believe that this is much +faster than simply making the two tagging calls in full: + +notmuch tag +to-me -- tag:new and tag:inbox and (to:sebastien.binet@cern.ch and not tag:to-me) +notmuch tag +sci-notmuch -- tag:new and tag:inbox and from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org or subject:notmuch" + +After the first call the cache will be fresh, so the overhead should be +minimal. It looks to me you're looking in to this as a post-new hook. +I do pretty much the same thing, and with the above properly constructed +searches the tagging is super fast. + +Have you tried profiling the two options? Is it really high I/O stress +on your system? If so, maybe there's another issue that can be +addressed. + +As an aside I should point out that a lot of people want to see the +"to:me" search term. But I think the right place to achieve that is in +the query parser. + +jamie. + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.12 (GNU/Linux) + +iQIcBAEBCAAGBQJP+v7xAAoJEO00zqvie6q8DUYP/iaZK9Y0Ve92jlIPiKyLkvYf +7xy6IcRLeph/VnHtbIIRskGeZrmNTjIIZjGHiwf35twaAm3Sfb6JedMheEv5ZUld +c/qUUA5eR2otJTe910aNAijOlHoeVRe0sG/S1wv0WIYBADlpnWU4pph5TbQQdcyv +/YdhhxKKlCPRDhojjzYcco46RkzietCO3AL3DulbJWqWVA3jC2dFDiu7RtuQCoXo +Lqr4eavU0/sYsGjoPWmJyF5Xrna57jLtPwJ+WlSeXTEBiz62rB8AsqRUv5WQu/Gr +DVZQebRG05I+yMteBr0UKko/Vk4IkePmO+/MdHM2sGkYA60AwIoxvhhgpLVaO1Tv +Y2NUmPcUFYSL5HOlfMBvhNF0dhW0HmyWISCGSNkal9px3nSybYp84xlA6gsH0uqg +H3ri3oP08orej94vpw9rXCqjL68YNS9NpNKdLXSn9o50U6ILBgjaSzVKXEOXxAGW +tRzcOIW0Vz0ryY1Hb2U/ryhTjEVTUzPqHQx16sMOIGnL4qvyt4YLvpRszrCQH4dW +HQ3XaeXMjz7MFqFV73u43AwJ7ln0fGjIAZ8FzhWvY6ZyOrT3te5vZy7MicEUs3zp +655EGIZ1wUvn9JY5UvEGED1s+rd4LNii8YBGzRCx83xCe9PphdVOpsbUnxs1hT7o +JbbyLteArCoFiwskE+MK +=yswv +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2