From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Vivekkumar Pandey <vivekkumar(dot)pandey(at)globallogic(dot)com> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres table have a large number of relpages and occupied a big memory size |
Date: | 2011-08-05 07:52:36 |
Message-ID: | CAJKUy5hKuKLi0n2F5xPJjLVB=EWMV50JV_-xideGayZrCL3k9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Aug 5, 2011 at 2:37 AM, Vivekkumar Pandey
<vivekkumar(dot)pandey(at)globallogic(dot)com> wrote:
>
> Hi Tomas,
>
> I am using the slony cluster and both the database have the same Data.
>
> So Please provide the appropriate solution....
>
> On Fri, Aug 5, 2011 at 12:47 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> >
> > That suggests you're using something else to build the cluster (e.g. slony
> > or something like that). In that case the size difference may be simply
> > due to data differences or dead tuples. VACUUM FULL should compact the
> > dead tuples, but it's not a cheap command (takes exclusive locks, time and
> > memory).
> >
It seems like Tomas gives you the solution (at least part of it): use
VACUUM FULL to compact your data on the master.
Also, probably you want to revisiti your autovacuum's configuration.
Finally, remember that Slony has two tables that logs all changes in
the database... normally only one of the table should be in use while
Slony is processing the queu of the other and truncate it. but if the
slon process are not running those tables start to grow... can you
check that the slon processes are running
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
From | Date | Subject | |
---|---|---|---|
Next Message | Vivekkumar Pandey | 2011-08-05 08:52:13 | Re: postgres table have a large number of relpages and occupied a big memory size |
Previous Message | Vivekkumar Pandey | 2011-08-05 07:37:50 | Re: postgres table have a large number of relpages and occupied a big memory size |