Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 50EBF633A7D for ; Fri, 16 Apr 2010 15:53:37 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 47385-03 for ; Fri, 16 Apr 2010 18:53:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 45E6A633942 for ; Fri, 16 Apr 2010 15:53:26 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lb6pZ-1NaMbp0w7F-00ki0f; Fri, 16 Apr 2010 20:53:13 +0200 Message-ID: <4BC8B216.8030201@2ndquadrant.com> Date: Fri, 16 Apr 2010 14:53:10 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Josh Kupershmidt CC: Tom Lane , Chris , pgsql-performance@postgresql.org Subject: Re: stats collector suddenly causing lots of IO References: <20100413170105.GA29571@chris-laptop.a2hosting.com> <25952.1271370711@sss.pgh.pa.us> <9738.1271431432@sss.pgh.pa.us> <10082.1271432484@sss.pgh.pa.us> <11152.1271436528@sss.pgh.pa.us> <4BC8A91D.9030709@2ndquadrant.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18yQHNU9Q8QEdJf8U3N7jJZ6nk1fa5UUebK7Mq ld6VM60GG1nlhW0oLCg+U8be0dHuS7jjrqAZUpme5nw1NxV3g4 YbV+AcqR0u26Xk3uvgIX0TL3Hq0fKuI X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.986 tagged_above=-10 required=5 tests=AWL=-0.086, BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201004/224 X-Sequence-Number: 38474 Josh Kupershmidt wrote: > And it seems the only way > to compact the pg_catalog tables is VACUUM FULL + REINDEX on 8.3 -- I > had tried the CLUSTER on my 9.0 machine and wrongly assumed it would > work on 8.3, too. > Right; that just got implemented a couple of months ago. See the news from http://www.postgresql.org/community/weeklynews/pwn20100214 for a summary of how the code was gyrated around to support that. This is a tough situation to get out of in <9.0 because VACUUM FULL is slow and takes an exclusive lock on the table. That tends to lead toward an unpredictable window for required downtime, which is never good. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us