Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 616579FA0C0 for ; Mon, 9 Oct 2006 17:31:06 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 95845-03 for ; Mon, 9 Oct 2006 17:31:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id 0A0289F9F0F for ; Mon, 9 Oct 2006 17:31:01 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Oct 2006 20:30:59 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 09 Oct 2006 15:30:59 -0500 Subject: Re: Simple join optimized badly? From: Scott Marlowe To: josh@agliodbs.com Cc: pgsql-performance@postgresql.org, Denis Lussier , Tom Lane , Bruce Momjian , "korryd@enterprisedb.com" , "Jonah H. Harris" , "Craig A. James" In-Reply-To: <200610081605.03501.josh@agliodbs.com> References: <45274A77.7080005@modgraph-usa.com> <18722.1160236300@sss.pgh.pa.us> <5f820f750610071850o6ed0b19o162d65d1987b2a8c@mail.gmail.com> <200610081605.03501.josh@agliodbs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1160425859.6181.18.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 09 Oct 2006 15:30:59 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.077 tagged_above=0 required=5 tests=AWL, SPF_PASS, UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200610/167 X-Sequence-Number: 21296 On Sun, 2006-10-08 at 18:05, Josh Berkus wrote: > Now, if you were offering us a patch to auto-populate the statistics as a > table is loaded, I'd be all for that. But I, personally, would need a > lot of convincing to believe that hints don't do more harm than good. Actually, I'd much rather have a log option, on by default, that spit out info messages when the planner made a guess that was off by a factor of 20 or 50 or so or more on a plan. I can remember to run stats, but finding slow queries that are slow because the plan was bad, that's the hard part.