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 1FC519DC820 for ; Thu, 15 Dec 2005 22:55:39 -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 37746-09 for ; Thu, 15 Dec 2005 22:55:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moonunit2.moonview.localnet (wsip-68-15-5-150.sd.sd.cox.net [68.15.5.150]) by postgresql.org (Postfix) with ESMTP id 058D99DC8A0 for ; Thu, 15 Dec 2005 22:55:36 -0400 (AST) Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3]) by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id jBG2trtA025718 for ; Thu, 15 Dec 2005 18:55:53 -0800 Message-ID: <43A22BE3.6020103@modgraph-usa.com> Date: Thu, 15 Dec 2005 18:52:19 -0800 From: "Craig A. James" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: pgsql-performance@postgresql.org Subject: Re: Overriding the optimizer 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> <43A226E7.7040508@paradise.net.nz> In-Reply-To: <43A226E7.7040508@paradise.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.113 required=5 tests=[AWL=-0.076, MISSING_HEADERS=0.189] X-Spam-Score: 0.113 X-Spam-Level: X-Archive-Number: 200512/373 X-Sequence-Number: 16194 Mark Kirkwood wrote: > I hear what you are saying, but to use this fine example - I don't know > what the best plan is - these experiments part of an investigation to > find *if* there is a better plan, and if so, why Postgres is not finding > it. > >> There isn't a database in the world that is as smart as a developer, >> or that can have insight into things that only a developer can >> possibly know. > > That is often true - but the aim is to get Postgres's optimizer closer > to developer smartness. What would be cool would be some way the developer could alter the plan, but they way of doing so would strongly encourage the developer to send the information to this mailing list. Postgres would essentially say, "Ok, you can do that, but we want to know why!" > After years of using several other database products (some supporting > hint type constructs and some not), I have come to believe that hinting > (or similar) actually *hinders* the development of a great optimizer. I agree. It takes the pressure off the optimizer gurus. If the users can just work around every problem, then the optimizer can suck and the system is still usable. Lest anyone think I'm an all-out advocate of overriding the optimizer, I know from first-hand experience what a catastrophe it can be. An Oracle hint I used worked fine on my test schema, but the customer's "table" turned out to be a view, and Oracle's optimizer worked well on the view whereas my hint was horrible. Unfortunately, without the hint, Oracle sucked when working on an ordinary table. Hints are dangerous, and I consider them a last resort. Craig