Received: from localhost (unknown [200.46.204.184])
	by developer.postgresql.org (Postfix) with ESMTP id 5F97F2E005C
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Mon, 28 Apr 2008 10:58:20 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 45173-02
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Mon, 28 Apr 2008 10:58:08 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175])
	by developer.postgresql.org (Postfix) with ESMTP id 38E192E0074
	for <pgsql-performance@postgresql.org>;
	Mon, 28 Apr 2008 10:58:16 -0300 (ADT)
Received: by ug-out-1314.google.com with SMTP id j3so712804ugf.49
	for <pgsql-performance@postgresql.org>;
	Mon, 28 Apr 2008 06:58:14 -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:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=kMmJQOzuLcleIyJyfhqOMKCh8bKpNkqWadk6GhxvO0o=;
	b=Z/2yFUHzkMMxOVzJfwMzEt3sdwoC/NW1Z5KM6SBCNTu4h4fcZjBhTYbJ6+xt7SuUcFyDHQIr+XjXPGCv5Cr5Cbg0pVO6ybvsK2fDOJZ+juQuJnd/tCg3XmUm7MyyisnDUCDoqDYadBMhuLK0JjECZs7rvtHumqRzRMGZNxVNWr8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:references;
	b=UMZdPRgGdFIKkIUX8CT58kh5ZiW1P+fkwQyZeCQ/UAu5OYbA/H7J9sT8PCAB0kX6GQiyHHcd3L08OXPHzVGF4mgSYcZkad6AlrlZAx6mkjdevjdd5Rjx1dnrFdTbZ0L6EzUlmWvV2gHlzu1t1PYDPZS04405jtyA/EQ6WMAE5CE=
Received: by 10.67.115.4 with SMTP id s4mr4931003ugm.1.1209391094415;
	Mon, 28 Apr 2008 06:58:14 -0700 (PDT)
Received: by 10.66.251.19 with HTTP; Mon, 28 Apr 2008 06:58:14 -0700 (PDT)
Message-ID: <a2de01dd0804280658t68ac22dsf182d304a94de5a2@mail.gmail.com>
Date: Mon, 28 Apr 2008 14:58:14 +0100
From: "Peter Childs" <peterachilds@gmail.com>
Subject: Re: Replication Syatem
Cc: pgsql-performance@postgresql.org
In-Reply-To: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3821_32133511.1209391094399"
References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=1.14 tagged_above=0 required=5 tests=AWL=-2.341,
	FS_REPLICA=1.179, HTML_MESSAGE=0.001, MISSING_HEADERS=1.581,
	SARE_SPEC_REPLICA=0.72
X-Spam-Level: *
X-Archive-Number: 200804/390
X-Sequence-Number: 29883

------=_Part_3821_32133511.1209391094399
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

------=_Part_3821_32133511.1209391094399
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">2008/4/28 Gauri Kanekar &lt;<a href="mailto:meetgaurikanekar@gmail.com">meetgaurikanekar@gmail.com</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
All,<br><br>We have a table &quot;table1&quot; 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 &quot;table1&quot; take almost 30min and during that time the site is down.<br>

<br>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.<br clear="all"><br>Can anybody guide which will be the best suited replication solution for this.<br>

<br>Thanx for any help<br><font color="#888888">~ Gauri<br>
</font></blockquote></div><br>I home your not using Vacuum Full....... (Standard Reply for this type of question)<br><br>What version of Postgresql are you using?<br><br>Have you tried autovacuum?<br><br>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.<br>
<br>If still have trouble run &quot;vacuum analyse verbose table1;&quot; and see what it says.<br><br>If your doing it right you should be able to vacuum with the database up.<br><br>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.<br>
<br>Regards<br><br>Peter.<br>

------=_Part_3821_32133511.1209391094399--