DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id;
	b=EtbdPioLrAmYJaDYyxVKknZWKEZ0p3ctU5ZB7e3Ry3cqBtw5dLoDcXL3CqG7WQMI94fH5W8k4QCe/RxB4mzbc3jakc0UMqSCfwAWiOzje3Tu7BHK7obG5eiA7wTTtxF/uTQBvjPzZDRMZh0tO1s3OBWNQTJVtcl6ps1kRbuiOmc=
From: Dimitri <dimitrik.fr@gmail.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Subject: Re: Parallel Vacuum
Date: Thu, 22 Mar 2007 16:55:02 +0100
User-Agent: KMail/1.9.3
Cc: pgsql-performance@postgresql.org
References: <200703221435.54408.dimitrik.fr@gmail.com>
	<200703221605.38460.dimitrik.fr@gmail.com>
	<20070322151243.GH4102@alvh.no-ip.org>
In-Reply-To: <20070322151243.GH4102@alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200703221655.03068.dimitrik.fr@gmail.com>

On Thursday 22 March 2007 16:12, Alvaro Herrera wrote:
> Dimitri escribi=F3:
> > On Thursday 22 March 2007 14:52, Alvaro Herrera wrote:
> > > Dimitri escribi=F3:
> > > > Folks,
> > > >
> > > > is there any constrains/problems/etc. to run several vacuum process=
es
> > > > in parallel while each one is 'vaccuming' one different table?
> > >
> > > No, no problem.  Keep in mind that if one of them takes a very long
> > > time, the others will not be able to remove dead tuples that were
> > > killed while the long vacuum was running -- unless you are in 8.2.
> >
> > Yes, I'm using the last 8.2.3 version. So, will they *really* processing
> > in parallel, or will block each other step by step?
>
> They won't block.

Wow! Excellent! :)
So, in this case why not to add 'parallel' option integrated directly into=
=20
the 'vacuumdb' command?=20

In my case I have several CPU on the server and quite powerful storage box=
=20
which is not really busy with a single vacuum. So, my idea is quite simple =
=2D=20
speed-up vacuum with parallel execution (just an algorithm):

=2D-------------------------------------------------------------------------
PLL=3Dparallel_degree
select tab_size, tabname, dbname from ... order by tab_size desc;
  vacuumdb -d $dbname -t $tabname  2>&1 > /tmp/vac.$dbname.$tabname.log &
  while (pgrep vacuumdb | wc -l ) >=3D $PLL
   sleep 1
  end
end
wait
=2D-------------------------------------------------------------------------

biggest tables are vacuumed first, etc.

But of course it will be much more cool to have something like:

   vacuumdb -a -P parallel_degree

What do you think? ;)

Rgds,
=2DDimitri