Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 5407C640252 for ; Tue, 24 Mar 2009 10:45:36 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 11523-02-5 for ; Tue, 24 Mar 2009 10:45:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 7D45F640259 for ; Tue, 24 Mar 2009 10:45:24 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n2ODjDfW026265; Tue, 24 Mar 2009 09:45:14 -0400 (EDT) To: Heikki Linnakangas cc: Sergey Burladyan , Oleg Bartunov , Teodor Sigaev , pgsql-performance@postgresql.org Subject: Re: Why creating GIN table index is so slow than inserting data into empty table with the same index? In-reply-to: <49C8BEF6.3080909@enterprisedb.com> References: <874oxjrb0p.fsf@seb.progtech.ru> <18581.1237865712@sss.pgh.pa.us> <49C8BEF6.3080909@enterprisedb.com> Comments: In-reply-to Heikki Linnakangas message dated "Tue, 24 Mar 2009 13:07:34 +0200" Date: Tue, 24 Mar 2009 09:45:13 -0400 Message-ID: <26264.1237902313@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.009 tagged_above=0 required=5 tests=AWL=0.009 X-Spam-Level: X-Archive-Number: 200903/345 X-Sequence-Number: 33267 Heikki Linnakangas writes: > Tom Lane wrote: >> I think a reasonable solution for this might be to keep an eye on >> maxdepth and force a flush if that gets too large (more than a few >> hundred, perhaps?). Something like this: > I fooled around with a balanced tree, which solved the problem but > unfortunately made the unsorted case slower. Yeah, rebalancing the search tree would fix that, but every balanced tree algorithm I know about is complicated, slow, and needs extra memory. It's really unclear that it'd be worth the trouble for a transient data structure like this one. regards, tom lane