Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id AF1659FB395 for ; Wed, 1 Nov 2006 15:02:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 47197-03-2 for ; Wed, 1 Nov 2006 15:01:48 -0400 (AST) X-Greylist: delayed 14:10:27.293398 by SQLgrey- Received: from ls405.htnet.hr (ls405.t-com.hr [195.29.150.135]) by postgresql.org (Postfix) with ESMTP id 91A4F9FB832 for ; Wed, 1 Nov 2006 08:05:55 -0400 (AST) Received: from ls422.t-com.hr (ls422.t-com.hr [195.29.150.237]) by ls405.htnet.hr (Postfix) with ESMTP id 61F4F1440C1 for ; Wed, 1 Nov 2006 13:05:52 +0100 (CET) Received: from ls422.t-com.hr (localhost.localdomain [127.0.0.1]) by ls422.t-com.hr (Qmlai) with ESMTP id 51347C9004A for ; Wed, 1 Nov 2006 13:05:52 +0100 (CET) X-Envelope-Sender-Info: KDHLkYIFXCRHG7zIR7FVXliUjXF6IZB7JSc0wf6GeGubZGHTINZXq7PaWxtuzQyk X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (89-172-55-35.adsl.net.t-com.hr [89.172.55.35])by ls422.t-com.hr (Qmlai) with ESMTP id EEF2E1308046for ; Wed, 1 Nov 2006 13:05:51 +0100 (CET) Message-ID: <45488DB1.9010005@fer.hr> Date: Wed, 01 Nov 2006 13:06:09 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: MVCC & indexes? References: <4547C65C.6090208@fer.hr> <20061031223632.GG12008@alvh.no-ip.org> In-Reply-To: <20061031223632.GG12008@alvh.no-ip.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-imss-version: 2.043 X-imss-result: Passed X-imss-scores: Clean:95.63330 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/10 X-Sequence-Number: 21780 Alvaro Herrera wrote: > Well, there certainly is locking involved in inserting index entries, > but it's more fine-grained than you seem to think. Only one page of the > index is locked at any time, resulting in that typically there's very > little blocking involved. Two processes can be inserting into the same > index concurrently (btree and GiST indexes at least; GiST only gained > concurrency in a recent release, I don't remember if it was 8.0 or 8.1). Thank you, this was the bit I was missing. In retrospect, I don't really know how I came to conclusion the whole index was being locked :(