Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id EF5959FB5E5 for ; Mon, 21 May 2007 06:49:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 09980-03 for ; Mon, 21 May 2007 06:49:13 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by postgresql.org (Postfix) with ESMTP id 27CEA9FB726 for ; Mon, 21 May 2007 06:49:16 -0300 (ADT) Received: by nz-out-0506.google.com with SMTP id s1so2184231nze for ; Mon, 21 May 2007 02:49:15 -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=ewnZyfOTSD9gsIbkn6YejXniazo49kIZen7Yfhp7mGWGnfsDbNU9L/xbgvmKL80bGrNJsrUH1NiX40VdeunB/bOdTaiOqWiZwy9ekxqcahHpvx5NnE1K2kPbhd2XFn0LW4LaO9brw3AaQG9hoCOpuicg2K2GiCbun/e+v7UtaXM= 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=Gt76NJ/b5EUYXbgPqsLqjHhONBbSvtEsYJGh/H8mCe7rUBw4Dqm4b6jc9mdO7Pva2sGHJ1Y4/WwsSlphTCjxJrTmBkty8ngtc+1xeIjfmeFoaMXdF67qgKWxgoIzl9BOJix79YEL7p/NUrpJTwKkLWkLwjuWcoqmE/4xaREjYOQ= Received: by 10.64.204.19 with SMTP id b19mr10439460qbg.1179740954880; Mon, 21 May 2007 02:49:14 -0700 (PDT) Received: from ?192.168.1.10? ( [82.13.36.26]) by mx.google.com with ESMTP id e17sm114415qba.2007.05.21.02.49.11; Mon, 21 May 2007 02:49:12 -0700 (PDT) Message-ID: <46516B0B.3000907@enterprisedb.com> Date: Mon, 21 May 2007 10:48:59 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Pavan Deolasee CC: Jaime Casanova , 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> <464F410C.8090900@enterprisedb.com> <2e78013d0705210117y6a65245cw426bbaafa9eb6419@mail.gmail.com> <2e78013d0705210232m5d031a6fk779be6d7df5a2e3c@mail.gmail.com> In-Reply-To: <2e78013d0705210232m5d031a6fk779be6d7df5a2e3c@mail.gmail.com> 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/377 X-Sequence-Number: 2477 Pavan Deolasee wrote: > On 5/21/07, Pavan Deolasee wrote: >> >> >> >> On 5/19/07, Heikki Linnakangas wrote: >> > >> > >> > Ah, sorry about that. For some reason my source tree was checked out >> > from the 8.2 branch, instead of CVS HEAD. >> > >> > >> I looked at the patch. Not that I am very comfortable with this part >> of the code, but nevertheless here are my comments: >> >> > Another problem that I noticed with the patch is that it disregards > the fillfactor while inserting the tuples. ISTM that this is a correct > behavior when a tuple is being inserted in the block to preserve cluster > ordering. But when the tuple is being inserted as a normal operation, > IMO we should respect the fillfactor. > > The easiest way to reproduce this is to insert tuples sorted on the > cluster index key. Actually it does respect the fillfactor when the block suggested by indexam is full. When you insert tuples sorted on the cluster index key, the suggested page after the first tuple on the new page is always the last page. Try inserting in random order instead. IOW it's working as designed. But maybe it's not the desired behavior. Should we have a special case and always respect the fillfactor when inserting to the last page of the heap? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com