Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5095A9FB6E2 for ; Sun, 17 Jun 2007 03:22:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 02800-09 for ; Sun, 17 Jun 2007 03:22:54 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by postgresql.org (Postfix) with ESMTP id 023499FB54A for ; Sun, 17 Jun 2007 03:22:53 -0300 (ADT) Received: by mu-out-0910.google.com with SMTP id i10so1759750mue for ; Sat, 16 Jun 2007 23:22:52 -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=mZVj/m7TY60JrxdT99ahyV5vCV9F6LzN3w2KM6mQbaDahiIO2YJVSzae+9I4TT4SvEKyYfZOhQv8zcARkwy/jlTkwhEF6W2qOIoaLmCIOjOosEYs6pv1mVpJZFGhdkG3loy4xbWcTq+m+M2WDLoV5Ct4zhIyLT/BJb6y4MLxRj8= 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=Ef/Hxc+EqWAerdhkep2tPCssXtJqoiFGKtxFflFet+/JUaiTxpPO5W6CkoM+wBPqaTxhw1CQ5KK379nFw0qyfxzgEOB3dJKamgKqiwG0kbL0mWdMWDaHHq1BbR+3pglq1XW4aecD3SNNqqM7VroK6ovMhjRuVNFZJ7dfQe5Shls= Received: by 10.82.134.12 with SMTP id h12mr8846712bud.1182061371817; Sat, 16 Jun 2007 23:22:51 -0700 (PDT) Received: from ?192.168.0.199? ( [80.222.48.97]) by mx.google.com with ESMTP id f6sm13164001nfh.2007.06.16.23.22.48 (version=SSLv3 cipher=RC4-MD5); Sat, 16 Jun 2007 23:22:49 -0700 (PDT) Message-ID: <4674D31B.9050000@enterprisedb.com> Date: Sun, 17 Jun 2007 07:22:19 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Jaime Casanova CC: "Jim C. Nasby" , Pavan Deolasee , PostgreSQL-patches Subject: Re: Maintaining cluster order on insert References: <464A33AB.1050401@enterprisedb.com> <464B15EF.4000808@enterprisedb.com> <464D96D6.1030608@enterprisedb.com> <464F410C.8090900@enterprisedb.com> <2e78013d0705210117y6a65245cw426bbaafa9eb6419@mail.gmail.com> <2e78013d0705210232m5d031a6fk779be6d7df5a2e3c@mail.gmail.com> <46516B0B.3000907@enterprisedb.com> <20070527190136.GR92628@nasby.net> In-Reply-To: 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: 200706/168 X-Sequence-Number: 2784 Jaime Casanova wrote: > On 5/27/07, Jim C. Nasby wrote: >> On Mon, May 21, 2007 at 10:48:59AM +0100, Heikki Linnakangas wrote: >> > >> > 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? >> >> I think that would be following with least surprise. > > What's the status of this patch? are we waiting an update? > > AFAIU, it's not fair to say that the patch maintain cluster order... > it just try to keep similar rows on the same page if possible (it's > not the same thing)... if it can't then it simply insert at the last > page as usual but we have wasted time in the try... That's right. Or more accurately, if there's no room on the same page, it uses the FSM and if it still can't find room, it inserts at the last page. > so the real question is if there is any performance win on this... > have you some numbers? Hmm. I ran a small test with random inserts/deletes back in August. The conclusion was that the table loses clustering a lot slower, but I can't find the results now. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com