From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Cuirass news Date: Tue, 13 Feb 2018 10:12:36 +0100 Message-ID: <20180213101236.5c74e577@scratchpost.org> References: <877es6x5xj.fsf@gnu.org> <87lggmjjgo.fsf@gmail.com> <87k1w6jjak.fsf@gmail.com> <87h8raxeym.fsf@gnu.org> <20180126153005.259a75e8@scratchpost.org> <87zi4z1eb0.fsf@gnu.org> <20180127181852.42f0bcbf@scratchpost.org> <87fu6bwqix.fsf@gnu.org> <20180208172905.19e9e789@scratchpost.org> <871shvt94p.fsf@gnu.org> <20180209000526.5b9ea8e7@scratchpost.org> <87wozm4i12.fsf@gnu.org> <20180209122931.5a47e63e@scratchpost.org> <877ermyuj2.fsf@gnu.org> <20180209180608.79fb856b@scratchpost.org> <874lmpw0rj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elWds-0004Yo-RN for guix-devel@gnu.org; Tue, 13 Feb 2018 04:12:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elWdp-0008Or-MI for guix-devel@gnu.org; Tue, 13 Feb 2018 04:12:48 -0500 In-Reply-To: <874lmpw0rj.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel Hi Ludo, On Sat, 10 Feb 2018 12:18:56 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Thinking about it, it wouldn=E2=80=99t matter that HTTP requests are proc= essed > sequentially if database queries run really fast. I=E2=80=99m not sure i= f we > can achieve it. WDYT? That depends on how fast. But it should be possible to optimize the actual query (using indices, lookups are O(log N)). Also, if it's the same query as before, it usually will be really fast as most of the pointers are still where they were before. Sqlite3 already automatically created indices for all the primary keys. There's also https://www.sqlite.org/pragma.html#pragma_optimize if we need = it. We can always try it with serialized database access and use a connection pool should it get too slow later.