Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 32638AF82E9 for ; Mon, 9 Jan 2012 11:48:23 -0400 (AST) Received: from gwmta.wicourts.gov ([165.219.244.99] helo=gw.wicourts.gov) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RkHSL-0008Ei-BZ for pgsql-admin@postgresql.org; Mon, 09 Jan 2012 15:48:22 +0000 Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Mon, 09 Jan 2012 09:48:03 -0600 Message-Id: <4F0AB7D002000025000445C2@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Mon, 09 Jan 2012 09:48:00 -0600 From: "Kevin Grittner" To: , "Silvio Brandani" Subject: Re: problem on table statistics References: <4F0AFC85.5050908@tech.sdb.it> In-Reply-To: <4F0AFC85.5050908@tech.sdb.it> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201201/42 X-Sequence-Number: 38954 Silvio Brandani wrote: > So there is something wrong with table statistics. It picks the plan which it calculates to have the lowest cost. If the lowest cost doesn't correspond to the fastest plan, the most common cause is that your costing factors need adjustment. > How can I reset the pg_statistics for this table??? It can also be that statistics are stale or are not fine-grained enough. You can get fresh statistics with the ANALYZE or VACUUM ANALYZE statements. You can change the granularity of statistics globally or for particular columns, but that just changes the behavior of subsequent ANALYZE runs; it doesn't force an immediate run. Your post was a little light on the sort of details which allow people to be most helpful. If problems persist, please read this before posting again: http://wiki.postgresql.org/wiki/SlowQueryQuestions -Kevin