Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 75A8A633551 for ; Mon, 4 Jan 2010 20:36:15 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 10007-05 for ; Tue, 5 Jan 2010 00:36:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp.iplink.net (smtp.iplink.net [192.139.81.186]) by mail.postgresql.org (Postfix) with ESMTP id 0ACBC6333D2 for ; Mon, 4 Jan 2010 20:36:05 -0400 (AST) Received: from [192.168.1.139] (unknown [64.34.156.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.iplink.net (Postfix) with ESMTP id AEE8DA13426; Mon, 4 Jan 2010 19:36:03 -0500 (EST) Message-ID: <4B428973.1000401@alteeve.com> Date: Mon, 04 Jan 2010 19:36:03 -0500 From: Madison Kelly User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Scott Marlowe Cc: Greg Smith , Steve Crawford , pgsql-performance@postgresql.org Subject: Re: DB is slow until DB is reloaded References: <4B423D22.7040803@alteeve.com> <4B424215.70605@pinpointresearch.com> <4B424FF6.40207@alteeve.com> <4B4260E6.7050502@pinpointresearch.com> <4B42638B.4000103@alteeve.com> <4B426823.4040001@2ndquadrant.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.189 tagged_above=-10 required=5 tests=BAYES_50=0.001, FH_DATE_PAST_20XX=3.188 X-Spam-Level: *** X-Archive-Number: 201001/32 X-Sequence-Number: 36912 Scott Marlowe wrote: > On Mon, Jan 4, 2010 at 3:13 PM, Greg Smith wrote: >> Madison Kelly wrote: >>> I think for now, I will stick with 8.1, but I will certainly try out your >>> repo edit above on a test machine and see how that works out. I am always >>> reticent to change something as fundamental as postgres without "good >>> reason". I guess I am a fan of "if it ain't broke...". :) >> PostgreSQL has many fundamental limitations that cannot be resolved no >> matter what you do in 8.1 that are fixed in later versions. The default >> behavior for the problem you're having has been massively improved by >> updates made in 8.2, 8.3, and 8.4. 8.1 can certainly be considered broken >> in regards to its lack of good and automatic VACUUM and ANALYZE behavior, >> and you're just seeing the first round of issues in that area. Every minute >> you spend applying temporary fixes to the fundamental issues is time you >> could be better spending toward upgrading instead. > > Also, the HOT updates in 8.3 made a compelling case for us to update, > and if the OP is suffering from table bloat, HOT might help a lot. > These are certainly compelling reasons for me to try upgrading... I will try a test upgrade on a devel server tomorrow using Steve's repo edits. Madi