Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 1AB699FC388 for ; Fri, 18 May 2007 12:19:36 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 64717-01 for ; Fri, 18 May 2007 12:19:32 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by postgresql.org (Postfix) with ESMTP id 963AD9FC390 for ; Fri, 18 May 2007 12:19:32 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id k3so443982ugf for ; Fri, 18 May 2007 08:19:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=ec3ny+SK+kACl1RR2WW6z81y16KfLb7kWF/98bYAqeNRtbuThz+Wm7XLXl3ZDW8hE/LnSzO7S43a6rxXqcsNS/r34CFUeL8Q54/Y0d/ccjxoMiqkF8JBlhwqZdmmF1YTgjrupr76Sf6Fp0LwFpvr/wTZBHUXxiF/3uztj+v/KEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=R2S136CE8Z86NDghIL6ExWlSqpH2tq0I+QeZGx5ta/ieK6XXj0gvqADXYgiGyZAViKURvfFUTZJ767C0F4s+7IkLsP2LpHIqUQX9n+KfTgcjz7GjYFkimDYUYojizE1LaBUULakEyw9Y3bGjAvRbGl0Bpjg6Ws9/DlfEP0+7EuA= Received: by 10.66.224.3 with SMTP id w3mr1138206ugg.1179501570546; Fri, 18 May 2007 08:19:30 -0700 (PDT) Received: from ?192.168.1.34? ( [86.27.73.11]) by mx.google.com with ESMTP id 5sm1696407ugc.2007.05.18.08.19.27; Fri, 18 May 2007 08:19:28 -0700 (PDT) Message-ID: <464DC3F6.502@enterprisedb.com> Date: Fri, 18 May 2007 16:19:18 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Tom Lane CC: Jaime Casanova , "Jim C. Nasby" , Bruce Momjian , PostgreSQL-patches Subject: Re: Maintaining cluster order on insert References: <200705152223.l4FMNJa17969@momjian.us> <464A33AB.1050401@enterprisedb.com> <20070516003810.GI20707@nasby.net> <464B15EF.4000808@enterprisedb.com> <464D96D6.1030608@enterprisedb.com> <27526.1179500906@sss.pgh.pa.us> In-Reply-To: <27526.1179500906@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/336 X-Sequence-Number: 2436 Tom Lane wrote: > Heikki Linnakangas writes: >> The beef of the patch is two new optional indexam API functions: >> amprepareinsert and amfinishinsert. amprepareinsert is called before >> inserting the heap tuple. It descends the tree and finds and pins the >> right leaf page to insert to, and returns a suggestion on where the heap >> tuple should be inserted. amfinishinsert is called after inserting the >> heap tuple to actually insert the index tuple. Documentation for these >> functions need to be added indexam.sgml, I noticed that that's not done yet. > > What happens when there's more than one index? You can only cluster a table on one index. The other index inserts will use the aminsert-function, after inserting the heap tuple as usual. > Is there a risk of deadlock during concurrent insertions (from different > processes trying to lock the same buffers in different orders)? No, should be ok. btprepareinsert function will release locks (but not the pin) after descending the tree, and btfinishinsert will reacquire them. The locking order is the same as today. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com