From: | akp geek <akpgeek(at)gmail(dot)com> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: FSM and VM file |
Date: | 2010-03-03 13:32:56 |
Message-ID: | 2024a9fb1003030532n90b6b6ta87bbdc49a9676df@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you all for the suggestions. I did a vacuum and the size has gone down
drastically. But still it is not the same size as my master. I am looking
into it
Appreicate your help
On Wed, Mar 3, 2010 at 4:41 AM, Richard Huxton <dev(at)archonet(dot)com> wrote:
> On 02/03/10 21:47, akp geek wrote:
>
>> I am doing a replication of one of the database and the size of the slave
>> database is growing exponentially . Right now the size of master db is
>> 849M
>> and the slave is 7GB.
>>
>
> my master is 8.3 and slave is 8.4
>>
>
> I'm guessing your slave isn't being vacuumed. Or, perhaps you have a
> long-running transaction on the slave that is preventing dead rows from
> being cleaned up.
>
> Two useful commands:
>
> vacuum verbose mytable;
>
> This will show you how many rows/pages can/should be cleaned up.
>
> SELECT pg_size_pretty( pg_total_relation_size('mytable') );
>
> This will show you the size of "mytable" (formatted nicely).
>
> --
> Richard Huxton
> Archonet Ltd
>
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2010-03-03 13:37:09 | Re: FSM and VM file |
Previous Message | Herouth Maoz | 2010-03-03 13:31:40 | stopping processes, preventing connections |