Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 2E2062E0061 for ; Mon, 28 Apr 2008 11:06:06 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 29132-05 for ; Mon, 28 Apr 2008 11:05:52 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by developer.postgresql.org (Postfix) with ESMTP id C948C2E005A for ; Mon, 28 Apr 2008 11:05:48 -0300 (ADT) Received: by el-out-1112.google.com with SMTP id j27so1559519elf.23 for ; Mon, 28 Apr 2008 07:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Bl8V91aAj8wMe0ZxOMxOyxCdrpzqpyHM3D7PwL10EvE=; b=sfO1lcSe7EXlQIqBhPQ/GMU7NSqk6fhvu7XWd3E+MQlOmJp18tZ0OiMT8eni5QElLpyWj//4PZzqoJibSUkurXQ9QUEBfb/WsP2SqrY2MW5B8/lt3lWBM9UjUtw+ZKbOD2B2jwOKqFKJoo3k2765639RxezSVZ6CUHLOIhdm394= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VSO7P4FbzsVkWb7mQFYaafGMa/6J6D5tzOdVpQKU/cbUEYSDDp/VRz91Y/jr9+w2K8tzRgmJ1zVQc/5Ds5iNLPUpv8ZU1wjOZmClp3vb83NMi9vPz5PeHM8wPWz2jYKutABF49ET7MsSAfh2x3sudscsZvLi6goM2zsBMzXq97c= Received: by 10.114.106.13 with SMTP id e13mr6442588wac.157.1209391537480; Mon, 28 Apr 2008 07:05:37 -0700 (PDT) Received: by 10.114.240.17 with HTTP; Mon, 28 Apr 2008 07:05:37 -0700 (PDT) Message-ID: <7e4ba9550804280705q43c51e66l104a5ff9272bbd4d@mail.gmail.com> Date: Mon, 28 Apr 2008 19:35:37 +0530 From: "Gauri Kanekar" To: "Peter Childs" Subject: Re: Replication Syatem Cc: pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5531_2745490.1209391537477" References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.9 tagged_above=0 required=5 tests=FS_REPLICA=1.179, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA=0.72 X-Spam-Level: * X-Archive-Number: 200804/391 X-Sequence-Number: 29884 ------=_Part_5531_2745490.1209391537477 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Peter, We are doing vacuum full every alternate day. We also do vacuum analyze very often. We are currently using 8.1.3 version. Auto vacuum is already on. But the table1 is so busy that auto vacuum don't get sufficient chance to vacuum it :(. Have already tried all the option listed by you, thats y we reached to the decision of having a replication sytsem. So any suggestion on that :). Thanx ~ Gauri On Mon, Apr 28, 2008 at 7:28 PM, Peter Childs wrote: > > > 2008/4/28 Gauri Kanekar : > > All, > > > > We have a table "table1" which get insert and updates daily in high > > numbers, bcoz of which its size is increasing and we have to vacuum it every > > alternate day. Vacuuming "table1" take almost 30min and during that time the > > site is down. > > > > We need to cut down on this downtime.So thought of having a replication > > system, for which the replicated DB will be up during the master is getting > > vacuumed. > > > > Can anybody guide which will be the best suited replication solution for > > this. > > > > Thanx for any help > > ~ Gauri > > > > I home your not using Vacuum Full....... (Standard Reply for this type of > question) > > What version of Postgresql are you using? > > Have you tried autovacuum? > > Run plain vacuum even more often on this even more often (like ever half > hour) and it should not take as long and save space. > > If still have trouble run "vacuum analyse verbose table1;" and see what it > says. > > If your doing it right you should be able to vacuum with the database up. > > Sounds like you might be happier a fix for the problem rather than a > complex work around which will actually solve a completely different > problem. > > Regards > > Peter. > -- Regards Gauri ------=_Part_5531_2745490.1209391537477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Peter,

We are doing vacuum full every alternate day. We also do vacuum analyze very often.
We are currently using 8.1.3 version.
Auto vacuum is already on. But the table1 is so busy that auto vacuum don't get sufficient chance to vacuum it :(.

Have already tried all the option listed by you, thats y we reached to the decision of having a replication sytsem. So any suggestion on that :).

Thanx
~ Gauri



On Mon, Apr 28, 2008 at 7:28 PM, Peter Childs <peterachilds@gmail.com> wrote:


2008/4/28 Gauri Kanekar <meetgaurikanekar@gmail.com>:

All,

We have a table "table1" which get insert and updates daily in high numbers, bcoz of which its size is increasing and we have to vacuum it every alternate day. Vacuuming "table1" take almost 30min and during that time the site is down.

We need to cut down on this downtime.So thought of having a replication system, for which the replicated DB will be up during the master is getting vacuumed.

Can anybody guide which will be the best suited replication solution for this.

Thanx for any help
~ Gauri

I home your not using Vacuum Full....... (Standard Reply for this type of question)

What version of Postgresql are you using?

Have you tried autovacuum?

Run plain vacuum even more often on this even more often (like ever half hour) and it should not take as long and save space.

If still have trouble run "vacuum analyse verbose table1;" and see what it says.

If your doing it right you should be able to vacuum with the database up.

Sounds like you might be happier a fix for the problem rather than a complex work around which will actually solve a completely different problem.

Regards

Peter.



--
Regards
Gauri ------=_Part_5531_2745490.1209391537477--