pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Gauri Kanekar <meetgaurikanekar@gmail.com>
Cc: Shane Ambler <pgsql@sheeky.biz>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Replication Syatem
Date: Wed, 30 Apr 2008 11:26:18 +0100
Message-ID: <4818494A.2050405@enterprisedb.com> (raw)
In-Reply-To: <7e4ba9550804292229x82e74e5y355349866c72245c@mail.gmail.com>
References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com>
	<a2de01dd0804280658t68ac22dsf182d304a94de5a2@mail.gmail.com>
	<7e4ba9550804280705q43c51e66l104a5ff9272bbd4d@mail.gmail.com>
	<20080428162243.GN2970@commandprompt.com>
	<7e4ba9550804282246p73c62fc6y5e7cb7dda55a6b50@mail.gmail.com>
	<Pine.GSO.4.64.0804290347560.20575@westnet.com>
	<7e4ba9550804290405i4c0d3a57x1640239c9995c13@mail.gmail.com>
	<20080429130204.GA5652@alvh.no-ip.org>
	<4817514A.3060704@Sheeky.Biz>
	<7e4ba9550804292229x82e74e5y355349866c72245c@mail.gmail.com>

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



view thread (48+ messages)  latest in thread

Message-ID: <4818494A.2050405@enterprisedb.com>
Permalink:  ../4818494A.2050405@enterprisedb.com/
Also on:    postgresql.org/message-id/4818494A.2050405@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: heikki@enterprisedb.com, meetgaurikanekar@gmail.com, pgsql@sheeky.biz, alvherre@commandprompt.com, gsmith@gregsmith.com
  Subject: Re: Replication Syatem
  In-Reply-To: <4818494A.2050405@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox