Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id B0ACB9FB378 for ; Mon, 9 Oct 2006 01:44:04 -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 47643-09 for ; Mon, 9 Oct 2006 01:44:01 -0300 (ADT) 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 07EB59FB350 for ; Mon, 9 Oct 2006 01:44:00 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k994ht9m019818; Mon, 9 Oct 2006 00:43:55 -0400 (EDT) To: Mark Kirkwood cc: "Craig A. James" , pgsql-performance@postgresql.org Subject: Re: Simple join optimized badly? In-reply-to: <4529C43A.3050503@paradise.net.nz> References: <45274A77.7080005@modgraph-usa.com> <18722.1160236300@sss.pgh.pa.us> <5f820f750610071850o6ed0b19o162d65d1987b2a8c@mail.gmail.com> <200610081605.03501.josh@agliodbs.com> <4529A0CA.8000904@modgraph-usa.com> <4529B6D0.2010206@paradise.net.nz> <4529B7E8.8080606@modgraph-usa.com> <4529C43A.3050503@paradise.net.nz> Comments: In-reply-to Mark Kirkwood message dated "Mon, 09 Oct 2006 16:38:34 +1300" Date: Mon, 09 Oct 2006 00:43:55 -0400 Message-ID: <19817.1160369035@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.092 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200610/154 X-Sequence-Number: 21283 Mark Kirkwood writes: > True enough - but (aside from the fact that hints might take just as > long to get into the development tree as cost-for-functions might take > to write and put in...) there is a nasty side effect to adding hints - > most of the raw material for optimizer improvement disappears (and hence > optimizer improvement stalls)- why? simply that everyone then hints > everything - welcome to the mess that Oracle are in (and seem to be > trying to get out of recently)! And *that* is exactly the key point here. Sure, if we had unlimited manpower we could afford to throw some at developing a hint language that would be usable and not too likely to break at every PG revision. But we do not have unlimited manpower. My opinion is that spending our development effort on hints will have a poor yield on investment compared to spending similar effort on making the planner smarter. Josh's post points out some reasons why it's not that easy to get long-term benefits from hints --- you could possibly address some of those problems, but a hint language that responds to those criticisms won't be trivial to design, implement, or maintain. See (many) past discussions for reasons why not. regards, tom lane