Skip site navigation (1) Skip section navigation (2)

Re: Replication Syatem

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Gauri Kanekar" <meetgaurikanekar(at)gmail(dot)com>
Cc: "Shane Ambler" <pgsql(at)sheeky(dot)biz>,"Alvaro Herrera" <alvherre(at)commandprompt(dot)com>,"Greg Smith" <gsmith(at)gregsmith(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Replication Syatem
Date: 2008-04-30 10:26:18
Message-ID: 4818494A.2050405@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Craig RingerDate: 2008-04-30 12:16:21
Subject: Re: Replication Syatem
Previous:From: Pavan DeolaseeDate: 2008-04-30 07:25:30
Subject: Re: Replication Syatem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group