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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2008-04-30 12:16:21 | Re: Replication Syatem |
Previous Message | Pavan Deolasee | 2008-04-30 07:25:30 | Re: Replication Syatem |