Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 5C6B8632304 for ; Fri, 25 Jun 2010 13:55:31 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 13575-03 for ; Fri, 25 Jun 2010 16:55:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id 4C0B1632277 for ; Fri, 25 Jun 2010 13:55:24 -0300 (ADT) Received: from [75.197.236.239] (239.sub-75-197-236.myvzw.com [75.197.236.239]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MMYL0-1OYDG21qHu-007zyf; Fri, 25 Jun 2010 18:55:21 +0200 Message-ID: <4C24DF75.4060502@2ndquadrant.com> Date: Fri, 25 Jun 2010 12:55:17 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Craig James CC: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Occasional giant spikes in CPU load References: <4BBCFB12.1010306@emolecules.com> <4BBD3A17.90209@emolecules.com> <4C23FD52.40508@emolecules.com> <23596.1277438692@sss.pgh.pa.us> <4C24B3BB.3070901@emolecules.com> <2286.1277477230@sss.pgh.pa.us> <4C24D679.7030701@emolecules.com> In-Reply-To: <4C24D679.7030701@emolecules.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+JrGbnH/VMrim8enowNI10i1RtjZ8zDU4OGwU ka4bQ0HAYYfYK/tdQUoBGLTgUeiL4JoIoZSIsD4MjWf+DZJ+nk ha6CoEm7+l84ATqJNiNeh6UhZoJg0ww X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/473 X-Sequence-Number: 39329 Craig James wrote: > if I upgrade a bloated database using the upgrade-in-place feature, > will 8.4.4 recover the bloat and return it to the OS, or do I still > have to recover the space manually (like vacuum-full/reindex, or > cluster, or copy/drop a table)? There's no way for an upgrade in place to do anything about bloat. The changes in 8.4 reduce the potential sources for new bloat (like running out of a FSM pages), and the overhead of running VACUUM drops some due to things like the "Partial VACUUM" changes. But existing bloated tables and indexes are moved forward to the new version without any change. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us