Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VUkgI-0005dy-Nf for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Oct 2013 21:55:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VUkgH-0000AV-HR for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Oct 2013 21:55:33 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VUkgF-0000AM-Sj for pgsql-hackers@postgresql.org; Fri, 11 Oct 2013 21:55:32 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VUkg7-0004cF-R1 for pgsql-hackers@postgresql.org; Fri, 11 Oct 2013 21:55:30 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id CFDCD508C2E for ; Fri, 11 Oct 2013 23:55:19 +0200 (CEST) X-Virus-Scanned: G-Hosting.cz + Station.cz + Klenot.cz + Subreg.cz amavisd-new at antispam.gransy.com Received: from mail.gransy.com ([82.208.44.189]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id rbciaWGIGmKh for ; Fri, 11 Oct 2013 23:55:32 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 80E9D508C34; Fri, 11 Oct 2013 23:55:19 +0200 (CEST) Received: from [192.168.1.227] (ip-78-45-139-138.net.upcbroadband.cz [78.45.139.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 5327E508C2E for ; Fri, 11 Oct 2013 23:55:19 +0200 (CEST) Message-ID: <525873C7.3070402@fuzzy.cz> Date: Fri, 11 Oct 2013 23:55:19 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: GIN improvements part 1: additional information References: <51CEA13C.8040103@vmware.com> <524E7C3B.7060402@vmware.com> <5250A7A1.2010701@fuzzy.cz> <52546434.1000303@vmware.com> <52548F79.6030407@fuzzy.cz> <52569635.5090808@vmware.com> In-Reply-To: <52569635.5090808@vmware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 10.10.2013 13:57, Heikki Linnakangas wrote: > On 09.10.2013 02:04, Tomas Vondra wrote: >> On 8.10.2013 21:59, Heikki Linnakangas wrote: >>> On 08.10.2013 17:47, Alexander Korotkov wrote: >>>> Hi, Tomas! >>>> >>>> On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote: >>>> >>>>> I've attempted to rerun the benchmarks tests I did a few weeks ago, >>>>> but >>>>> I got repeated crashes when loading the data (into a table with >>>>> tsvector+gin index). >>>>> >>>>> Right before a crash, theres this message in the log: >>>>> >>>>> PANIC: not enough space in leaf page! >>>>> >>>> >>>> Thanks for testing. Heikki's version of patch don't works for me too on >>>> even much more simplier examples. I can try to get it working if he >>>> answer >>>> my question about GinDataLeafPageGetPostingList* macros. >>> >>> The new macros in that patch version were quite botched. Here's a new >>> attempt. >> >> Nope, still the same errors :-( >> >> PANIC: not enough space in leaf page! >> LOG: server process (PID 29722) was terminated by signal 6: Aborted >> DETAIL: Failed process was running: autovacuum: ANALYZE public.messages > > I've continued hacking away at the patch, here's yet another version. > I've done a lot of cleanup and refactoring to make the code more > readable (I hope). I'm not sure what caused the panic you saw, but it's > probably fixed now. Let me know if not. Yup, this version fixed the issues. I haven't been able to do any benchmarks yet, all I have is some basic stats | HEAD | patched ====================================== load duration | 1084 s | 1086 s subject index | 96 MB | 96 MB body index | 2349 MB | 2051 MB So there's virtually no difference in speed (which is expected, AFAIK) and the large index on full message bodies is significantly smaller. regards Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers