Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id A48CE2E0037 for ; Wed, 30 Apr 2008 11:46:46 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 70985-05 for ; Wed, 30 Apr 2008 11:46:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 4728D2E002D for ; Wed, 30 Apr 2008 11:46:42 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m3UEkSZm018685; Wed, 30 Apr 2008 10:46:28 -0400 (EDT) To: "Pavan Deolasee" cc: "Gauri Kanekar" , "Shane Ambler" , "Alvaro Herrera" , "Greg Smith" , pgsql-performance@postgresql.org Subject: Re: Replication Syatem In-reply-to: <2e78013d0804300025j10567a82x5845ab8bc3d4f2a2@mail.gmail.com> References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> <7e4ba9550804290405i4c0d3a57x1640239c9995c13@mail.gmail.com> <20080429130204.GA5652@alvh.no-ip.org> <4817514A.3060704@Sheeky.Biz> <7e4ba9550804292229x82e74e5y355349866c72245c@mail.gmail.com> <2e78013d0804292237l4c74a166u4ab082901aa0804f@mail.gmail.com> <7e4ba9550804292239n668b1f01v59ad7ac6ca9e092b@mail.gmail.com> <2e78013d0804292343hd9d1c0lf93df68e559f9af3@mail.gmail.com> <7e4ba9550804292346r46aa55e7g6cf1f731b6be7d40@mail.gmail.com> <2e78013d0804300025j10567a82x5845ab8bc3d4f2a2@mail.gmail.com> Comments: In-reply-to "Pavan Deolasee" message dated "Wed, 30 Apr 2008 12:55:30 +0530" Date: Wed, 30 Apr 2008 10:46:28 -0400 Message-ID: <18684.1209566788@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/467 X-Sequence-Number: 29960 "Pavan Deolasee" writes: > That's weird. With that fillfactor, you should have a very high > percentage of HOT update ratio. It could be a very special case that > we might be looking at. He's testing >> update table1 set delta1 = 100 where code/1000000 =999; so all the rows being updated fall into a contiguous range of "code" values. If the table was loaded in such a way that those rows were also physically contiguous, then the updates would be localized and would very soon run out of freespace on those pages. regards, tom lane