X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 2E3F19DC842 for ; Fri, 13 Jan 2006 20:22:08 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 29851-03 for ; Fri, 13 Jan 2006 20:22:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id C5A5D9DC838 for ; Fri, 13 Jan 2006 20:22:02 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id A89D23983D; Fri, 13 Jan 2006 18:22:05 -0600 (CST) Date: Fri, 13 Jan 2006 18:22:05 -0600 From: "Jim C. Nasby" To: Ott? Havasv?lgyi Cc: pgsql-performance@postgresql.org Subject: Re: Throwing unnecessary joins away Message-ID: <20060114002205.GP9017@pervasive.com> References: <34608c0c0601120418n1af567b9n@mail.gmail.com> <43C64CFB.9030504@barettadeit.com> <34608c0c0601120541wd910da3s@mail.gmail.com> <5269.1137081233@sss.pgh.pa.us> <34608c0c0601120900l7d26073dp@mail.gmail.com> <1137085382.3959.16.camel@state.g2switchworks.com> <34608c0c0601121051r52c707f6l@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34608c0c0601121051r52c707f6l@mail.gmail.com> X-Operating-System: FreeBSD 6.0-RELEASE amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.09 required=5 tests=[AWL=0.090] X-Spam-Score: 0.09 X-Spam-Level: X-Archive-Number: 200601/173 X-Sequence-Number: 16651 On Thu, Jan 12, 2006 at 07:51:22PM +0100, Ott? Havasv?lgyi wrote: > Hi, > > If the join is to a primary key or notnull unique column(s), then > inner join is also ok. But of course left join is the simpler case. > An example: Actually, you need both the unique/pk constraint, and RI (a fact I missed in the email I just sent). Nullability is another consideration as well. But there certainly are some pretty common cases that can be optimized for. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461