Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbSoJ-0003jV-Tb for pgsql-performance@postgresql.org; Thu, 22 Nov 2012 09:11:04 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbSoH-0001Bi-F4 for pgsql-performance@postgresql.org; Thu, 22 Nov 2012 09:11:02 +0000 Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 24A1C28527; Thu, 22 Nov 2012 01:11:00 -0800 (PST) Received: from zcs-prod-ext-mta-2.vmware.com (zcs-prod-ext-mta-2.vmware.com [10.113.62.224]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 19B4918536; Thu, 22 Nov 2012 01:11:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-2.vmware.com (Postfix) with ESMTP id EB9E9C1A85; Thu, 22 Nov 2012 01:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at zcs-prod-ext-mta-2.vmware.com Received: from zcs-prod-ext-mta-2.vmware.com ([127.0.0.1]) by localhost (zcs-prod-ext-mta-2.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n7xaanQ1VbMG; Thu, 22 Nov 2012 01:10:59 -0800 (PST) Received: from [192.168.1.90] (unknown [10.113.62.14]) by zcs-prod-ext-mta-2.vmware.com (Postfix) with ESMTPSA id C3177C1A81; Thu, 22 Nov 2012 01:10:57 -0800 (PST) Message-ID: <50ADEC21.9060700@vmware.com> Date: Thu, 22 Nov 2012 11:10:57 +0200 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: Jeff Janes CC: Kevin Grittner , Craig Ringer , Craig James , Tom Lane , Claudio Freire , Merlin Moncure , David Greco , pgsql-performance@postgresql.org Subject: Re: Hints (was Poor performance using CTE) References: <20121121134232.68590@gmx.com> <50ACFBBD.30204@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -7.3 (-------) X-Archive-Number: 201211/251 X-Sequence-Number: 48617 On 22.11.2012 02:53, Jeff Janes wrote: >> That gives the planner the information it needs to choose the right plan on >> its own. That kind of hints would be much less implementation specific and >> much more likely to still be useful, or at least not outright >> counter-productive, in a future version with a smarter planner. > > When I run into unexpectedly poor performance, I have an intuitive > enough feel for my own data that I know what plan it ought to be > using. Figuring out why it is not using it is very hard. For one > thing, EXPLAIN tells you about the "winning" plan, but there is no > visibility into what ought to be the winning plan but isn't, so no way > to see why it isn't. So you first have to use our existing non-hint > hints (enable_*, doing weird things with cost_*, CTE stuff) to trick > it into using the plan I want it to use, before I can figure out why > it isn't using it, before I could figure out what hints of the style > you are suggesting to supply to get it to use it. I'm sure that happens too, but my gut feeling is that more often the EXPLAIN ANALYZE output reveals a bad estimate somewhere in the plan, and the planner chooses a bad plan based on the bad estimate. If you hint the planner by giving a better estimate for where the estimator got it wrong, the planner will choose the desired plan. - Heikki