On Mon, 23 Nov 2009 19:43:26 -0800, Keith Packard <keithp@keithp.com> wrote: > On Mon, 23 Nov 2009 19:16:54 -0800, Carl Worth <cworth@cworth.org> 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