Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D8A3F9FB3B5 for ; Sun, 8 Oct 2006 23:41:34 -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 24423-05 for ; Sun, 8 Oct 2006 23:41:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-4.paradise.net.nz (linda-4.paradise.net.nz [203.96.152.183]) by postgresql.org (Postfix) with ESMTP id E5ECF9FB360 for ; Sun, 8 Oct 2006 23:41:30 -0300 (ADT) Received: from smtp-3.paradise.net.nz (tclsnelb1-src-1.paradise.net.nz [203.96.152.172]) by linda-4.paradise.net.nz (Paradise.net.nz) with ESMTP id <0J6U00DSMKT3IJ@linda-4.paradise.net.nz> for pgsql-performance@postgresql.org; Mon, 09 Oct 2006 15:41:28 +1300 (NZDT) Received: from [192.168.1.11] (218-101-28-171.dsl.clear.net.nz [218.101.28.171]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id 2162F1562F8; Mon, 09 Oct 2006 15:41:27 +1300 (NZDT) Date: Mon, 09 Oct 2006 15:41:20 +1300 From: Mark Kirkwood Subject: Re: Simple join optimized badly? In-reply-to: <4529A0CA.8000904@modgraph-usa.com> To: "Craig A. James" Cc: josh@agliodbs.com, pgsql-performance@postgresql.org Message-id: <4529B6D0.2010206@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5.0.7 (X11/20061003) 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> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.039 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200610/147 X-Sequence-Number: 21276 Craig A. James wrote: > > > My example, discussed previously in this forum, is a classic. I have a > VERY expensive function (it's in the class of NP-complete problems, so > there is no faster way to do it). There is no circumstance when my > function should be used as a filter, and no circumstance when it should > be done before a join. But PG has no way of knowing the cost of a > function, and so the optimizer assigns the same cost to every function. > Big disaster. > > The result? I can't use my function in any WHERE clause that involves > any other conditions or joins. Only by itself. PG will occasionally > decide to use my function as a filter instead of doing the join or the > other WHERE conditions first, and I'm dead. > this is an argument for cost-for-functions rather than hints AFAICS. It seems to me that if (in addition to the function cost) we come up with some efficient way of recording cross column statistics we would be well on the way to silencing *most* of the demands for hints. We would still be left with some of the really difficult problems - a metric for "locally correlated" column distributions and a reliable statistical algorithm for most common value sampling (or a different way of approaching this). These sound like interesting computer science or mathematics thesis topics, maybe we could try (again?) to get some interest at that level? Cheers Mark