Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id A361B9FBBE7 for ; Thu, 22 Mar 2007 15:23:22 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 77586-03 for ; Thu, 22 Mar 2007 15:23:12 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by postgresql.org (Postfix) with ESMTP id C33AB9FBB16 for ; Thu, 22 Mar 2007 15:23:11 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id x4so1667366nfb for ; Thu, 22 Mar 2007 11:23:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=EZAFvXg0LX5//UYtG21HOv0cbR6EYm0mQvAQ91QqiMuXEIWhCrWiQtNdlZ64tLrQVAT94mT6IQP+Zno5X3hRpzQiDFaAtJTzLUV/XoE+h2VLVF59A+OJXgQM2JNSTHiIwVxJ7keke4qiaFiU3OuWM7Acd/oavI0lsv/py20nCvc= 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=Jhtzq9zs0tGzWZAbpHC0dW15Lmi2FpQSIiLkPe4hPwheuu7rWi5LvOUWT2G3uto8TlfcDGbUJOAeUeNqQp8tz9vCkDW30rv06zz48wfsZNRe8dLSpTxVGUXXtN/qQGEdhml4WojjNVVPlUGOX0y721c8nwZyolO+diO/4B2R/20= Received: by 10.78.200.3 with SMTP id x3mr1112211huf.1174587790229; Thu, 22 Mar 2007 11:23:10 -0700 (PDT) Received: from ?192.168.18.160? ( [194.206.227.18]) by mx.google.com with ESMTP id m16sm9322361nfc.2007.03.22.11.23.09; Thu, 22 Mar 2007 11:23:09 -0700 (PDT) From: Dimitri To: pgsql-performance@postgresql.org Subject: Re: Parallel Vacuum Date: Thu, 22 Mar 2007 19:24:38 +0100 User-Agent: KMail/1.9.3 Cc: Michael Stone References: <200703221435.54408.dimitrik.fr@gmail.com> <200703221655.03068.dimitrik.fr@gmail.com> <20070322171007.GH11402@mathom.us> In-Reply-To: <20070322171007.GH11402@mathom.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703221924.39278.dimitrik.fr@gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/348 X-Sequence-Number: 23753 Mike, you're right until you're using a single disk :) Now, imagine you have more disks - more I/O operations you may perform, and you'll need also a CPU time to process them :) until you fully use one CPU per 'vacuumdb' - and then you stop... As well, even in case when CPU is not highly used by vacuumdb - single process is still not able to get a max performance of the storage array, just because you need several concurrent I/O running in the system to reach max throughput. And even filesystem might help you here - it's not all... More concurrent writers you have - higher performance you reach (until real limit)... In my case I have a small storage array capable to give you more than 500MB/sec and say 5000 op/s. All my data are striped throw all array disks. Single 'vacuumdb' process here become more CPU-bound rather I/O as it cannot fully load storage array... So, more vacuum processes I start in parallel - faster I'll finish database vacuuming. Best regards! -Dimitri On Thursday 22 March 2007 18:10, Michael Stone wrote: > On Thu, Mar 22, 2007 at 04:55:02PM +0100, Dimitri wrote: > >In my case I have several CPU on the server and quite powerful storage box > >which is not really busy with a single vacuum. So, my idea is quite simple > > - speed-up vacuum with parallel execution (just an algorithm): > > Vacuum is I/O intensive, not CPU intensive. Running more of them will > probably make things slower rather than faster, unless each thing you're > vacuuming has its own (separate) disks. The fact that your CPU isn't > pegged while vacuuming suggests that your disk is already your > bottleneck--and doing multiple sequential scans on the same disk will > definitely be slower than doing one. > > Mike Stone > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq