Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 4A2559FB25A for ; Tue, 10 Oct 2006 16:26:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 21146-07 for ; Tue, 10 Oct 2006 19:26:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id A10029FA27F for ; Tue, 10 Oct 2006 16:26:26 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 285D156435; Tue, 10 Oct 2006 14:26:25 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 10 Oct 2006 14:26:23 -0500 Date: Tue, 10 Oct 2006 14:26:23 -0500 From: "Jim C. Nasby" To: Josh Berkus Cc: pgsql-performance@postgresql.org, Tom Lane , Tobias Brox , Chris Browne Subject: Re: Simple join optimized badly? Message-ID: <20061010192623.GL72517@nasby.net> References: <20061009213303.GA19144@oppetid.no> <17519.1160489688@sss.pgh.pa.us> <20061010142101.GD72517@nasby.net> <200610101028.30191.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610101028.30191.josh@agliodbs.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:061010:josh@agliodbs.com::WTCvk/y93yPwfut1:00000000000000000000 0000000000000000000000002VQM X-Hashcash: 1:20:061010:pgsql-performance@postgresql.org::Yorqa+wMjAvtfr4y:00000 00000000000000000000000039RV X-Hashcash: 1:20:061010:tgl@sss.pgh.pa.us::PGlv6EZbEc4cuU88:00000000000000000000 00000000000000000000000069Xa X-Hashcash: 1:20:061010:tobias@nordicbet.com::iLStpFncK1JKJ9sz:00000000000000000 0000000000000000000000000wWQ X-Hashcash: 1:20:061010:cbbrowne@acm.org::ciSyjyWsNDUgLGvT:03qH1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200610/207 X-Sequence-Number: 21336 On Tue, Oct 10, 2006 at 10:28:29AM -0700, Josh Berkus wrote: > Jim, > > > We've depricated things before, I'm sure we'll do it again. Yes, it's a > > pain, but it's better than not having anything release after release. > > And having a formal hint language would at least allow us to eventually > > clean up some of these oddball cases, like the OFFSET 0 hack. > > > > I'm also not convinced that even supplimental statistics will be enough > > to ensure the planner always does the right thing, so query-level hints > > may have to stay (though it'd be great if that wasn't the case). > > "stay"? I don't think that the general developers of PostgreSQL are going > to *accept* anything that stands a significant chance of breaking in one > release. You have you challange for the EDB development team: come up > with a hinting language which is flexible enough not to do more harm than > good (hint: it's not Oracle's hints). My point was that I think we'll always have a need for fine-grained (ie: table and join level) hints, even if we do get the ability for users to over-ride the statistics system. It's just not possible to come up with automation that will handle every possible query that can be thrown at a system. I don't see how that means breaking anything in a given release. Worst-case, the optimizer might be able to do a better job of something than hints written for an older version of the database, but that's going to be true of any planner override we come up with. BTW, I'm not speaking for EnterpriseDB or it's developers here... query hints are something I feel we've needed for a long time. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)