Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7CA6F650121 for ; Tue, 2 Sep 2008 07:41:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 44889-03 for ; Tue, 2 Sep 2008 07:41:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by postgresql.org (Postfix) with ESMTP id 65270650030 for ; Tue, 2 Sep 2008 07:41:27 -0300 (ADT) Received: by ey-out-2122.google.com with SMTP id 6so888295eyi.61 for ; Tue, 02 Sep 2008 03:41:26 -0700 (PDT) Received: by 10.210.81.3 with SMTP id e3mr8113832ebb.22.1220352085821; Tue, 02 Sep 2008 03:41:25 -0700 (PDT) Received: from ?80.222.42.69? ( [80.222.42.69]) by mx.google.com with ESMTPS id h1sm5926902nfh.19.2008.09.02.03.41.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Sep 2008 03:41:25 -0700 (PDT) Message-ID: <48BD1852.1070904@enterprisedb.com> Date: Tue, 02 Sep 2008 13:41:22 +0300 Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Simon Riggs CC: List pgsql-patches Subject: Re: WIP Join Removal References: <1220176372.4371.118.camel@ebony.2ndQuadrant> <48BC4127.30706@enterprisedb.com> <1220348487.4371.307.camel@ebony.2ndQuadrant> <48BD1374.4030504@enterprisedb.com> <1220352112.4371.349.camel@ebony.2ndQuadrant> In-Reply-To: <1220352112.4371.349.camel@ebony.2ndQuadrant> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Heikki Linnakangas X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/8 X-Sequence-Number: 7023 Simon Riggs wrote: > On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> It turns out that a join like this >>> >>> select a.col2 >>> from a left outer join b on a.col1 = b.col1 >>> where b.col2 = 1; >>> >>> can be cheaper if we don't remove the join, when there is an index on >>> a.col1 and b.col2, because the presence of b allows the values returned >>> from b to be used for an index scan on a. >> Umm, you *can't* remove that join. > > Yes, you can. The presence or absence of rows in b is not important to > the result of the query because of the "left outer join". > > I spent nearly a whole day going down that deadend also. Oh. How does the query look like after removing the join, then? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com