Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VV1rK-0001w6-KO for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Oct 2013 16:16:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VV1rJ-0001nR-Vc for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Oct 2013 16:16:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VV1rI-0001nI-N3 for pgsql-hackers@postgresql.org; Sat, 12 Oct 2013 16:16:04 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VV1rF-0007O7-Ur for pgsql-hackers@postgresql.org; Sat, 12 Oct 2013 16:16:04 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 28071508C0B for ; Sat, 12 Oct 2013 18:15:59 +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 A9E4uAvuA96r for ; Sat, 12 Oct 2013 18:16:08 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 3C164508C15; Sat, 12 Oct 2013 18:15:58 +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 0E9C6508C0B for ; Sat, 12 Oct 2013 18:15:58 +0200 (CEST) Message-ID: <525975BD.3080403@fuzzy.cz> Date: Sat, 12 Oct 2013 18:15:57 +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> <525873C7.3070402@fuzzy.cz> In-Reply-To: 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 12.10.2013 12:11, Alexander Korotkov wrote: > On Sat, Oct 12, 2013 at 1:55 AM, Tomas Vondra > wrote: > > 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. > > > Yes, it should be no significant difference in speed. But difference in > index sizes seems to be too small. Could you share database dump somewhere? Turns out that if I do VACUUM FULL after loading the data (a sequence of INSERT commands), the index sizes drop significantly. | HEAD | patched ====================================== subject index | 42 MB | 15 MB body index | 624 MB | 328 MB So there's a significant improvement, as expected. I'm wondering if the bloat is expected too? Is that the consequence of incremental index updates vs. rebuilding the whole index at once during VACUUM FULL? Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers