Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 77F7564FC9D for ; Wed, 3 Dec 2008 02:58:00 -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 19176-02 for ; Wed, 3 Dec 2008 02:57:57 -0400 (AST) X-Greylist: delayed 10:44:48.723305 by SQLgrey-1.7.6 Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.178]) by mail.postgresql.org (Postfix) with ESMTP id A5D0764FC4E for ; Wed, 3 Dec 2008 02:57:57 -0400 (AST) Received: by ik-out-1112.google.com with SMTP id c21so3070524ika.3 for ; Tue, 02 Dec 2008 22:57:56 -0800 (PST) Received: by 10.210.51.10 with SMTP id y10mr15008061eby.87.1228287475983; Tue, 02 Dec 2008 22:57:55 -0800 (PST) Received: from ?80.223.223.193? (dsl-hkibrasgw2-fedfdf00-193.dhcp.inet.fi [80.223.223.193]) by mx.google.com with ESMTPS id c4sm3602676nfi.13.2008.12.02.22.57.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Dec 2008 22:57:54 -0800 (PST) Message-ID: <49362DF0.80404@enterprisedb.com> Date: Wed, 03 Dec 2008 08:57:52 +0200 Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Tom Lane CC: Teodor Sigaev , 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> <493541F5.2020401@enterprisedb.com> <26721.1228266365@sss.pgh.pa.us> In-Reply-To: <26721.1228266365@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; 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/118 X-Sequence-Number: 128747 Tom Lane wrote: > Heikki Linnakangas writes: >> 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. > > Doesn't work --- the index would yield wrong answers for later queries > in the same transaction. Queries would still need to check the backend-private list. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com