Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id B1E209FB2A7 for ; Thu, 18 Jan 2007 16:21:52 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 35257-09 for ; Thu, 18 Jan 2007 16:21:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by postgresql.org (Postfix) with ESMTP id E72A89FB2A3 for ; Thu, 18 Jan 2007 16:21:48 -0400 (AST) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 8155A849A6; Thu, 18 Jan 2007 15:21:47 -0500 (EST) Received: from web2.messagingengine.com ([10.202.2.211]) by out1.internal (MEProxy); Thu, 18 Jan 2007 15:21:47 -0500 Received: by web2.messagingengine.com (Postfix, from userid 99) id 3A9ECF480; Thu, 18 Jan 2007 15:21:47 -0500 (EST) Message-Id: <1169151707.6247.1169971737@webmail.messagingengine.com> X-Sasl-Enc: d3Q/JbTyTQwBsAodVdmz7LZovYw9uq7oYbDfF4uCZQ9v 1169151707 From: "Jeremy Haile" To: "Matthew T. O'Connor" Cc: pgsql-performance@postgresql.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1169145474.20103.1169962769@webmail.messagingengine.com> <45AFC86B.9010704@zeut.net> Subject: Re: Autoanalyze settings with zero scale factor In-Reply-To: <45AFC86B.9010704@zeut.net> Date: Thu, 18 Jan 2007 15:21:47 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/316 X-Sequence-Number: 22917 > Unless it's just a bug, my only guess is that autovacuum may be getting > busy at times (vacuuming large tables for example) and hasn't had a > chance to even look at that table for a while, and by the time it gets > to it, there have been tens of thousands of inserts. Does that sounds > plausible? Possible, but I think your next suggestion is more likely. > Also, are other auto-vacuums and auto-analyzes showing up in the > pg_stats table? Maybe it's a stats system issue. No tables have been vacuumed or analyzed today. I had thought that this problem was due to my pg_autovacuum changes, but perhaps not. I restarted PostgreSQL (in production - yikes) About a minute after being restarted, the autovac process fired up. What could get PG in a state where autovac isn't running? Is there anything I should watch to debug or monitor for this problem in the future? I wish I'd noticed whether or not the stats collector process was running before I restarted.