Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 7A94AB5DBC4 for ; Wed, 15 Jun 2011 05:04:16 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 33948-06 for ; Wed, 15 Jun 2011 08:04:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by mail.postgresql.org (Postfix) with ESMTP id 369BFB5D95B for ; Wed, 15 Jun 2011 05:04:06 -0300 (ADT) Received: from mail-ey0-f181.google.com ([209.85.215.181]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTfhndAxaNqiNxjjQPs4H1Pukj1EBCzG4@postini.com; Wed, 15 Jun 2011 01:04:07 PDT Received: by eyh5 with SMTP id 5so63655eyh.26 for ; Wed, 15 Jun 2011 01:04:03 -0700 (PDT) Received: by 10.213.106.196 with SMTP id y4mr206558ebo.29.1308125043348; Wed, 15 Jun 2011 01:04:03 -0700 (PDT) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id s11sm178786eef.15.2011.06.15.01.04.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 01:04:01 -0700 (PDT) Message-ID: <4DF8676F.9040801@enterprisedb.com> Date: Wed, 15 Jun 2011 11:03:59 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.2.17) Gecko/20110510 Icedove/3.1.10 MIME-Version: 1.0 To: Alexander Korotkov CC: pgsql-hackers Subject: Re: WIP: Fast GiST index build References: <4DEC84D7.7040602@enterprisedb.com> <4DECB141.2040707@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201106/1241 X-Sequence-Number: 189954 On 15.06.2011 10:24, Alexander Korotkov wrote: > On Wed, Jun 15, 2011 at 11:21 AM, Alexander Korotkov > wrote: > >> I've tried index tuples sorting on penalty function before buffer >> relocation on split. But it was without any success. Index quality becomes >> even worse than without sorting. >> The next thing I've tried is buffer relocation between all neighbor >> buffers. Results of first tests is much more promising. Number of page >> accesses during index scan is similar to those without fast index build. I'm >> going to hold on this approach. >> >> test=# create index test_idx on test using gist(v); >> NOTICE: Level step = 1, pagesPerBuffer = 406 >> CREATE INDEX >> Time: 10002590,469 ms >> > I forget to say that build time increases in about 40%, but it is still > faster than ordinal build in about 10 times. Is this relocation mechanism something that can be tuned, for different tradeoffs between index quality and build time? In any case, it seems that we're going to need a lot of testing with different data sets to get a better picture of how this performs. But at least for now, it looks like this approach is going to be acceptable. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com