From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-3.6 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no
	autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 176341F452;
	Wed, 12 Apr 2023 20:17:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org;
	s=selector1; t=1681330663;
	bh=ijHeD31H4qlfqnIUYMLV6CRtm1uplo78bgVJKxi4H/g=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=gXOWFIwYxfQKin/8pJwXh3+DOrDLuL4IUJ+oN0Hbfnmb5IYNiV/RfRThxFmxhHBIC
	 PzfOHdFgORhE4F5oVYaxjv5Qnsi+97ZPsb0USAYPCDW5Tlpga+3xn2h7vWT7lpM3zd
	 xTs7EsEFuW6gjlkpkJdaZBmqvjRqiTHuAXjufJmU=
Date: Wed, 12 Apr 2023 20:17:42 +0000
From: Eric Wong <e@80x24.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Jacob Keller <jacob.e.keller@intel.com>, meta@public-inbox.org
Subject: Re: search by whole thread?
Message-ID: <20230412201743.M20097@dcvr>
References: <f8156a76-f4ac-8fc3-0eae-0c3a1a927ddb@intel.com>
 <20230412000654.M9394@dcvr>
 <20230412-vividness-expectant-b3c889@meerkat>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230412-vividness-expectant-b3c889@meerkat>
List-Id: <meta.public-inbox.org>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Apr 12, 2023 at 12:06:53AM +0000, Eric Wong wrote:
> > I think the reason it's rare in MUAs is that it's potentially
> > very expensive.  But I think the `thread:{subquery}' feature
> > from notmuch I discussed with Konstantin the other week[1] can
> > do what you want it to do.
> > 
> > Keep in mind, notmuch-search-terms(7) states:
> > 
> > 	The performance of such queries can vary wildly.
> > 
> > And that's for a private client tool for a single user.
> 
> Yes, when I was wondering about that, it was really for the lei side of
> things. I don't really want to run expensive queries on lore (though I'm okay
> if we can turn it off for /all/ or other very large lists).

I expect relying on timeouts in an external process will be fine
for lore, especially since some expensive queries are already
possible :x

I suppose ITIMER_REAL is better than RLIMIT_CPU since the former
accounts for I/O time.  Xapian makes a lot of small pread
syscalls so I don't see it being stuck in D-state long on SSDs.