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 1FB46431FBC for ; Tue, 24 Nov 2009 02:19:37 -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 85DatuwuGCCL for ; Tue, 24 Nov 2009 02:19:35 -0800 (PST) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by olra.theworths.org (Postfix) with ESMTP id 20F1E431FAE for ; Tue, 24 Nov 2009 02:19:34 -0800 (PST) Received: by bwz2 with SMTP id 2so6097166bwz.0 for ; Tue, 24 Nov 2009 02:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject :in-reply-to:references:date:message-id:mime-version:content-type; bh=I65d9swiqW8aSIBnmOfqJezwxR2W9MK4TC1hodFq5yA=; b=w4xPr4aeevbv+S+W0eCpNFo+qGmusPg0mARFlAjmJYDOvZN3yntJEzxjVdydKrtJit KvvMGv78g0X2AKGMfpdYQiJjMl9VFqv4Km9j4V3p1XFE17FiYzfaqNskWQgcAF8Xfa2j Muj8rw4n65Zk8owopfWWjuMmQTV1yBXvQC8Zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:in-reply-to:references:date:message-id :mime-version:content-type; b=O1pO1W0HnO+q0JJJ+APkG54Ry3k50hwTzm97kTEL/SZUKlZKms4/uuXjxsEg8rq3I1 V8RPGQNSzISb0H5k8x9izxeHa9wphzqrMEAbTXsz1H3oaIsd8eWvTgPBjRs3GRIkw02l VlOTLR0/4StyKg6JIeDpq8NpLP1lMKIz0z93Q= Received: by 10.204.24.17 with SMTP id t17mr5953037bkb.142.1259057972872; Tue, 24 Nov 2009 02:19:32 -0800 (PST) Received: from kunyang (vawpc43.ethz.ch [129.132.59.11]) by mx.google.com with ESMTPS id 1sm6964695fkt.3.2009.11.24.02.19.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 02:19:31 -0800 (PST) Sender: Jed Brown From: Jed Brown To: Keith Packard , Carl Worth , notmuch@notmuchmail.org In-Reply-To: References: <87639122sx.fsf@yoom.home.cworth.org> <87bpismx21.fsf@yoom.home.cworth.org> Date: Tue, 24 Nov 2009 11:20:02 +0100 Message-ID: <87tywkp6lp.fsf@59A2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [notmuch] notmuch 'index' mode. X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.12 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: Tue, 24 Nov 2009 10:19:37 -0000 On Mon, 23 Nov 2009 19:43:26 -0800, Keith Packard wrote: > On Mon, 23 Nov 2009 19:16:54 -0800, Carl Worth wrote: > > Then tags become something that are just for manual manipulation. What > > do you think? I really think this is the way to go. > And disadvantages as searching might actually be slow at some point? If this happens, there is nothing to prevent notmuch from caching the search by actually writing a corresponding tag. This could be made automatic by logging the cost of each named search (and perhaps the frequency of making that search), and using a tradeoff function to decide which searches to optimize. Once a search was selected for optimization, there are at least two alternatives, depending on which queries xapian can answer quickly. 1. Log the time and spawn an asynchronous notmuch tag process. Searches for vtag:named-search (vtag: doesn't need to be a keyword, but I'm only distinguishing here for clarity) which was normally translated into long search expression becomes tag:named-search OR newer:timestamp AND (long search expression) This option guarantees that notmuch new remains fast and simple because it does no special tagging, but this query might not be any better. 2. Inform notmuch new that it should apply the chosen tag to messages matching the query and spawn the asynchronous notmuch tag process. Once the tag process has finished, searches for vtag:named-search are translated to tag:named-search. This implies concurrent modification of the database, otherwise it would cause a stall in incoming mail (not important if mass tagging somehow became faster). Admittedly my archive is not huge (100k messages in 3.5 GB plus 1.1 GB for .notmuch) but queries returning a reasonable number of messages are still quite fast. Additionally, searches for tags do not seem to be greatly faster than queries for complex queries returning a similar number of results. Jed