X-Original-To: pgsql-sql@postgresql.org Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 02C1F475A4B for ; Tue, 18 Mar 2003 12:29:12 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.8/8.12.8) with ESMTP id h2IHTHub026875; Tue, 18 Mar 2003 12:29:17 -0500 (EST) To: chester c young Cc: pgsql-sql@postgresql.org Subject: Re: outer join versus not exists In-reply-to: <20030318165427.52097.qmail@web12703.mail.yahoo.com> References: <20030318165427.52097.qmail@web12703.mail.yahoo.com> Comments: In-reply-to chester c young message dated "Tue, 18 Mar 2003 08:54:27 -0800" Date: Tue, 18 Mar 2003 12:29:16 -0500 Message-ID: <26874.1048008556@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200303/441 X-Sequence-Number: 12480 chester c young writes: > In pg, is there any performance gain in using outer join with null as > versus using not exists, eg: > select t1.* from t1 right join t2 using( id ) where t2.id is null; You meant a left join here, no? > versus > select * from t1 where not exists (select 1 from t2 where t1.id=t2.id); It depends. Either one could be substantially better than the other, depending on the data statistics. If many of the t1 rows have multiple matches in t2, I'd think that the join approach would lose, because it would generate lots of joined rows that only get thrown away. If t2.id is unique (and indexed), then the exists approach would probably give you a plan approximately equivalent to a nestloop with inner indexscan on t2. This would be one of the alternatives considered for the join, so the join should be at least as fast as the exists, possibly faster if the planner can find a faster plan involving merge or hash joining. regards, tom lane