From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Cuirass news Date: Mon, 19 Feb 2018 16:35:06 +0100 Message-ID: <20180219163506.2037e56e@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> <20180213101236.5c74e577@scratchpost.org> <87zi4bsn37.fsf@gnu.org> <877erfqhy4.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]:55860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ennTL-0001YP-T6 for guix-devel@gnu.org; Mon, 19 Feb 2018 10:35:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ennTH-00027N-IB for guix-devel@gnu.org; Mon, 19 Feb 2018 10:35:19 -0500 In-Reply-To: <877erfqhy4.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 Thu, 15 Feb 2018 00:17:55 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Turns out creating the relevant indexes helps a lot, unsurprisingly I > guess: >=20 > https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=3Ddb= 27955ad3fae260ee2aa4bace8dd6a4115d338c Yup. It's a tradeoff because now the DBMS has to update the indices every = time you insert or update, but reading is now faster. I guess we query more than we build so it's fine. > I also discovered SQLite=E2=80=99s =E2=80=9CEXPLAIN QUERY PLAN=E2=80=9D, = which is pretty cool: >=20 > https://www.sqlite.org/lang_explain.html Yup :) > With that /latestbuilds still usually takes a bit more than 2 seconds. > This could be due to the repeated =E2=80=98Outputs=E2=80=99 queries via = =E2=80=98db-get-outputs=E2=80=99. Oh yeah, I wanted to optimize that. It won't be that nice but it will be faster. First, I'll send a patch simplifying db-get-builds while retaining the current functionality.