X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 92E6A9DC9D7 for ; Thu, 15 Dec 2005 20:23:49 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 04808-09 for ; Thu, 15 Dec 2005 20:23:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 701C59DC820 for ; Thu, 15 Dec 2005 20:23:47 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jBG0NnuW018538; Thu, 15 Dec 2005 19:23:49 -0500 (EST) To: "Craig A. James" cc: pgsql-performance@postgresql.org Subject: Re: Overriding the optimizer In-reply-to: <43A1F6DB.3080805@modgraph-usa.com> References: <200512141603.52583.blargity@gmail.com> <7484.1134600423@sss.pgh.pa.us> <1134629567.14248.27.camel@firebolt> <200512150148.16125.blargity@gmail.com> <1134644526.14248.60.camel@firebolt> <43A1C40D.8040006@paradise.net.nz> <43A1F6DB.3080805@modgraph-usa.com> Comments: In-reply-to "Craig A. James" message dated "Thu, 15 Dec 2005 15:06:03 -0800" Date: Thu, 15 Dec 2005 19:23:49 -0500 Message-ID: <18537.1134692629@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.002 required=5 tests=[AWL=0.002] X-Spam-Score: 0.002 X-Spam-Level: X-Archive-Number: 200512/362 X-Sequence-Number: 16183 "Craig A. James" writes: > I see this over and over. Tweak the parameters to "force" a certain > plan, because there's no formal way for a developer to say, "I know > the best plan." I think you've misunderstood those conversations entirely. The point is not to force the planner into a certain plan, it is to explore what's going on with a view to understanding why the planner isn't making a good choice, and thence hopefully improve the planner in future. (Now, that's not necessarily what the user with an immediate problem is thinking, but that's definitely what the developers are thinking.) > There isn't a database in the world that is as smart as a developer, People who are convinced they are smarter than the machine are often wrong ;-). If we did put in the nontrivial amount of work needed to have such a facility, it would probably get abused more often than it was used correctly. I'd rather spend the work on making the planner better. This discussion has been had before (many times) ... see the -hackers archives for detailed arguments. The one that carries the most weight in my mind is that planner hints embedded in applications will not adapt to changing circumstances --- the plan that was best when you designed the code might not be best today. regards, tom lane