X-Original-To: pgsql-sql@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 180FA476070 for ; Sun, 2 Mar 2003 06:54:04 -0500 (EST) Received: from postgresql.org ([64.49.215.8]) by localhost (postgresql.org [64.49.215.8:10024]) (amavisd-new) with SMTP id 85431-04 for ; Sun, 2 Mar 2003 06:54:02 -0500 (EST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id 118B8475CA6 for ; Sun, 2 Mar 2003 02:33:00 -0500 (EST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 599A2D617; Sat, 1 Mar 2003 23:33:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 4F54A5C04; Sat, 1 Mar 2003 23:33:00 -0800 (PST) Date: Sat, 1 Mar 2003 23:33:00 -0800 (PST) From: Stephan Szabo To: Tom Lane Cc: Nicolas Fertig , Subject: Re: OUTER JOIN with filter In-Reply-To: <16210.1046588957@sss.pgh.pa.us> Message-ID: <20030301232815.Q24208-100000@megazone23.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Archive-Number: 200303/45 X-Sequence-Number: 12085 On Sun, 2 Mar 2003, Tom Lane wrote: > Stephan Szabo writes: > > On Sat, 1 Mar 2003, Nicolas Fertig wrote: > >> Can anyone help me with the problem bellow ? > >> > >> SELECT TM.some_field, TS.name > >> FROM table_main TM > >> LEFT OUTER JOIN (SELECT name FROM table_slave WHERE c1 = 'myvalue') TS > >> USING(id) > > > select tm.some_field, ts.name > > from table_main tm left outer join table_slave ts > > on (tm.id=ts.id and ts.c1='myvalue'); > > Offhand I believe that these queries should generate identical plans. > They do not at the moment --- the second one generates a worse plan > (sorry Stephan ;-)) --- because the planner does not realize it could I wasn't really sure if it would or not (wrote it without testing on a running server), actually I didn't realize it wouldn't push down, and figured it'd give pretty much the same plan, but it is less verbose. :) > push down the ts.c1='myvalue' JOIN condition into the scan of ts, even > though the join is OUTER. But AFAICS it would not change the results to > do so; ts rows failing ts.c1='myvalue' will not produce join output > anyway, but would allow outer-joined lefthand rows to be produced. (Can > anyone see a hole in that logic? It's on my to-do list to change it...) I don't see an obvious case where it'd be different either.