Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 1F82E1337B8D for ; Thu, 10 Feb 2011 13:06:52 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 28783-06 for ; Thu, 10 Feb 2011 17:06:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp.peak6.com (smtp.peak6.com [38.98.137.6]) by mail.postgresql.org (Postfix) with ESMTP id 7DDFC1337B7E for ; Thu, 10 Feb 2011 13:06:44 -0400 (AST) X-AuditID: 0a64cb1e-b7c55ae000000bfb-55-4d541b235d16 Message-ID: <4D541B22.9080000@peak6.com> Date: Thu, 10 Feb 2011 11:06:42 -0600 From: Shaun Thomas Reply-To: sthomas@peak6.com Organization: Peak6 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Kevin Grittner CC: Josh Berkus , Robert Haas , "pgsql-performance@postgresql.org" Subject: Re: Why we don't want hints Was: Slow count(*) again... References: <201102012247.p11Ml6u02682@momjian.us> <4D48914B.4050403@dunslane.net> <4D489AD1.1010105@vmsinfo.com> <4D499E55.4020107@vmsinfo.com> <4D49A6B9.4060608@2ndquadrant.com> <4D49C482.4010707@vmsinfo.com> <4D49F0BA.9000901@2ndquadrant.com> <4D4A16BF.1020304@vmsinfo.com> <4D4A4844.3020409@2ndquadrant.com> <4D4AD9F6.6040903@vmsinfo.com> <4D4AE16E.9040807@peak6.com> <4D4B17B4.9030406@vmsinfo.com> <4D4B1F5B.4060403@peak6.com> <4D4B261B.6010303@vmsinfo.com> <4D4B2E8A.7010402@vmsinfo.com> <4D4B3395.6010007@agliodbs.com> <4D4B394E.9080505@vmsinfo.com> <4D4B5A73.3080302@agliodbs.com> <4D53C1C0020000250003A783@gw.wicourts.gov> In-Reply-To: <4D53C1C0020000250003A783@gw.wicourts.gov> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAZE= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/331 X-Sequence-Number: 42469 On 02/10/2011 10:45 AM, Kevin Grittner wrote: > Even there I would tend to think that the sort of "do it this way" > hints that people seem to initially want wouldn't be good; it should > be a way to override the costing factor which the optimizer gets > wrong, so it can do its usual excellent job of evaluating plans with > accurate costs. You know... that's an interesting approach. We already do that with functions by allowing users to specify the estimated cost, rows returned, and even override config settings. It's an inexact science at best, but it might help the optimizer out. Really... how difficult would it be to add that syntax to the JOIN statement, for example? -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@peak6.com ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email