From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:58115) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1aBc-0001x4-0X for guix-patches@gnu.org; Tue, 11 Feb 2020 13:23:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1aBb-0001Th-0j for guix-patches@gnu.org; Tue, 11 Feb 2020 13:23:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51537) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1aBa-0001Sl-TB for guix-patches@gnu.org; Tue, 11 Feb 2020 13:23:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1aBa-0000jp-IH for guix-patches@gnu.org; Tue, 11 Feb 2020 13:23:02 -0500 Subject: [bug#39258] Faster guix search using an sqlite cache Resent-Message-ID: MIME-Version: 1.0 References: <8736bhytn9.fsf@gnu.org> In-Reply-To: <8736bhytn9.fsf@gnu.org> From: zimoun Date: Tue, 11 Feb 2020 19:21:55 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Arun Isaac , 39258@debbugs.gnu.org Hi Ludo, On Tue, 11 Feb 2020 at 17:29, Ludovic Court=C3=A8s wrote: > I would rather keep the current package cache as-is instead of inserting > sqlite in here. I don=E2=80=99t expect it to bring much compared > performance-wise to the current simple cache (especially if we look at > load time), and it does increase complexity quite a bit. Complexity is about taste. ;-) About performance, the idea was to first implement something with sqlite and then see if it makes the difference. I mean I have understood that. > However, using sqlite for keyword search as you initially proposed on > guix-devel does sound like a great idea to me. If I understand correctly, you are proposing 2 caches, right? Or are you proposing an inverted index (VHash/VList table) based on trigrams to speed up the lookup? Cheers, simon