| 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: | Whole Thread | Raw Message | 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 |