Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 271266325F3 for ; Mon, 29 Mar 2010 13:33:17 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 10102-09 for ; Mon, 29 Mar 2010 16:33:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id A7D1F63246F for ; Mon, 29 Mar 2010 13:33:05 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MaFzQ-1OG1he05Tk-00KU02; Mon, 29 Mar 2010 18:33:04 +0200 Message-ID: <4BB0D63C.90408@2ndquadrant.com> Date: Mon, 29 Mar 2010 12:33:00 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Tom Lane CC: Robert Haas , Simon Riggs , pgsql-hackers@postgresql.org Subject: Re: enable_joinremoval References: <1269851630.3684.3636.camel@ebony> <603c8f071003290637q14d431f7j90afabd6fd2ec952@mail.gmail.com> <12679.1269873374@sss.pgh.pa.us> <603c8f071003290820h3553d223le3b5228f789608f9@mail.gmail.com> <4BB0CF3D.8090701@2ndquadrant.com> <603c8f071003290910l310c0e18v6b8986a22c6c4836@mail.gmail.com> <14825.1269879474@sss.pgh.pa.us> In-Reply-To: <14825.1269879474@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+xSpqLUVG83omF5Yf2l7v/+HPArNGqdx/xGS5 sBxbwtP7a5tOaQyosmOR0zU2JK9NVZHrE7os7uSZqTjAJjmQyK ZA+IPekOoGyLDg4eh9KtTZlwvmQSZt4 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.446 tagged_above=-10 required=5 tests=AWL=-0.706, BAYES_20=-0.74 X-Spam-Level: X-Archive-Number: 201003/1161 X-Sequence-Number: 159937 Tom Lane wrote: > The problem with this line of thought is that it imagines you can look > at worked-out alternative plans. You can't, because the planner doesn't > pursue rejected alternatives that far (and you'd not want to wait long > enough for it to do so...) > Not on any production system, sure. I know plenty of people who would gladly let a rejected plan enumerator run for *a day* on their development box if it let them figure out exactly why the costing on the plan they expected ended up higher than the plan they actually get. While I know you don't run into this, regular people can easily spend a week on one such problem without gaining even that much insight, given the current level of instrumentation and diagnostic tools available. "Read the source" and "ask Tom" are both effective ways to resolve that but have their limits. (Not because of you, of course--my bigger problem are people who just can't share their plans with the lists for privacy or security reasons) -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us