Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id B65D36330AB for ; Fri, 13 Feb 2009 20:02:23 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 27544-03 for ; Fri, 13 Feb 2009 20:02:16 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by mail.postgresql.org (Postfix) with ESMTP id B62816330AF for ; Fri, 13 Feb 2009 20:02:13 -0400 (AST) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id CAFFC3FE4 for ; Sat, 14 Feb 2009 01:02:09 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id A66D5400166 for ; Sat, 14 Feb 2009 01:02:09 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: pgsql-admin@postgresql.org Subject: Re: Vacuum wait time problem Date: Sat, 14 Feb 2009 01:02:09 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; ) References: <4995ABC0.4090401@musicreports.com> In-Reply-To: <4995ABC0.4090401@musicreports.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902140102.09224@zmi.at> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200902/95 X-Sequence-Number: 31316 On Freitag 13 Februar 2009 Roger Ging wrote: > I'm running vacuum full analyze verbose on a table with 20million > rows and 11 indexes. =A0In top, I'm seeing [pdflush] and postgres: > writer process each using diferent cpu cores, with wait time well > above 90% on each of them. =A0The vacuum has been running for several > hours Roger, I've had the same issue some time ago and wondered why it was so=20 slow. I did "iostat -kx 5 555" and saw that I/O was also quite low. vacuum_cost_delay =3D 0 That was the trick for me. It was set to 250(ms), where it took 5 hours=20 for a vacuum to run. Now it takes 5-15 minutes. And for your bloated table, you should also REINDEX afterwards, because=20 likely the index will be a mess also. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4