Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 38FE22E007A for ; Wed, 30 Apr 2008 07:26:32 -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 53328-08 for ; Wed, 30 Apr 2008 07:26:25 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (webmail.enterprisedb.com [63.246.7.168]) by developer.postgresql.org (Postfix) with ESMTP id 1393F2E0041 for ; Wed, 30 Apr 2008 07:26:28 -0300 (ADT) thread-index: AciqrL72qR/RwLRwQoClJ9oxQM5leg== Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Received: from [172.24.32.184] ([62.232.55.118]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 06:27:09 -0400 Message-ID: <4818494A.2050405@enterprisedb.com> Date: Wed, 30 Apr 2008 11:26:18 +0100 From: "Heikki Linnakangas" Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: "Gauri Kanekar" Cc: "Shane Ambler" , "Alvaro Herrera" , "Greg Smith" , Subject: Re: Replication Syatem References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> <7e4ba9550804280705q43c51e66l104a5ff9272bbd4d@mail.gmail.com> <20080428162243.GN2970@commandprompt.com> <7e4ba9550804282246p73c62fc6y5e7cb7dda55a6b50@mail.gmail.com> <7e4ba9550804290405i4c0d3a57x1640239c9995c13@mail.gmail.com> <20080429130204.GA5652@alvh.no-ip.org> <4817514A.3060704@Sheeky.Biz> <7e4ba9550804292229x82e74e5y355349866c72245c@mail.gmail.com> In-Reply-To: <7e4ba9550804292229x82e74e5y355349866c72245c@mail.gmail.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2008 10:27:09.0343 (UTC) FILETIME=[BEDED2F0:01C8AAAC] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/462 X-Sequence-Number: 29955 Gauri Kanekar wrote: > HOT doesn't seems to be working in our case. > > This is "table1" structure : > id integer not null > code integer not null > crid integer not null > status character varying(1) default 'A'::character varying > delta1 bigint default 0 > delta2 bigint default 0 > delta3 bigint default 0 > delta4 bigint default 0 > tz_id integer default 0 > Indexes: > "idx1" PRIMARY KEY, btree (id) > "idx2" UNIQUE, btree (code, crid) > "idx3" btree (tz_id) > "idx4" btree (status) > > code as crid are foreign key. > > Here delta* fields get updated through out the day. and most of the time it > may update the same row again n again. > > table1 contains around 12843694 records. > > Now not understanding y HOT don't work in our case. > > Changed fillfactor to 80, 75,70.... but nothing seems to work. Did you dump and reload the table after setting the fill factor? It only affects newly inserted data. Another possibility is that there's a long running transaction in the background, preventing HOT/vacuum from reclaiming the dead tuples. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com