Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C346664FE01 for ; Tue, 2 Dec 2008 10:11:15 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 06082-10 for ; Tue, 2 Dec 2008 10:11:12 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mail.postgresql.org (Postfix) with ESMTP id 76E36650212 for ; Tue, 2 Dec 2008 10:11:12 -0400 (AST) Received: by ey-out-2122.google.com with SMTP id 6so1387431eyi.61 for ; Tue, 02 Dec 2008 06:11:10 -0800 (PST) Received: by 10.210.29.11 with SMTP id c11mr5927901ebc.176.1228227070677; Tue, 02 Dec 2008 06:11:10 -0800 (PST) Received: from ?192.168.0.199? (dsl-hkibrasgw2-fe49de00-183.dhcp.inet.fi [80.222.73.183]) by mx.google.com with ESMTPS id d23sm25245689nfh.11.2008.12.02.06.11.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Dec 2008 06:11:09 -0800 (PST) Message-ID: <493541F5.2020401@enterprisedb.com> Date: Tue, 02 Dec 2008 16:11:01 +0200 Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Teodor Sigaev CC: Tom Lane , Pgsql Hackers Subject: Re: [PATCHES] GIN improvements References: <483FD205.4090904@sigaev.ru> <486BC501.6060605@sigaev.ru> <27880.1215810535@sss.pgh.pa.us> <487A6E0C.3090600@sigaev.ru> <8993.1216843701@sss.pgh.pa.us> <4888A594.6010102@sigaev.ru> <490B07BA.6030109@sigaev.ru> <492F04D9.5070404@enterprisedb.com> <49353081.9030304@sigaev.ru> In-Reply-To: <49353081.9030304@sigaev.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit From: Heikki Linnakangas X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/73 X-Sequence-Number: 128702 Teodor Sigaev wrote: > - Falling back to regular insert will take long time for update of whole > table - and that was one of reasons of that patch. Users forget to drop > GIN index before a global update and query runs forever. If *that* is a use case we're interested in, the incoming tuples could be accumulated in backend-private memory, and inserted into the index at commit. That would be a lot simpler, with no need to worry about concurrent inserts or vacuums. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com