RE: should one use ANSI join syntax when writing an Oracle applic ation?

  • From: "Ken Naim" <kennaim@xxxxxxxxx>
  • To: <Brandon.Allen@xxxxxxxxxxx>, <paul.baumgartel@xxxxxxxxxxxxxxxxx>, <breitliw@xxxxxxxxxxxxx>, <Jacques.Kilchoer@xxxxxxxxx>
  • Date: Thu, 19 Oct 2006 16:12:54 -0500

Well, I know for a fact that this is the case in 10g as it happened to me
just the other day. I had a situation where a.x=b.x and a.x in
('a','b','c',.... etc.)  and the optimizer choose to use an index on b.x

Ken

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Allen, Brandon
Sent: Thursday, October 19, 2006 11:50 AM
To: paul.baumgartel@xxxxxxxxxxxxxxxxx; breitliw@xxxxxxxxxxxxx;
Jacques.Kilchoer@xxxxxxxxx
Cc: oracle-l
Subject: RE: should one use ANSI join syntax when writing an Oracle applic
ation?

I thought Oracle was smart enough to perform transitive closure on its
own even if you don't explicitly write it in your SQL, e.g. Metalink
#68979.1:

"Transitivity and Transitive Closure
===================================

Purpose
~~~~~~~
This article explains how the Cost Based Optimizer (CBO) generates
transitive
predicates to open potential new access methods."


> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx 
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Baumgartel, Paul
> Wolfgang,
> 
> Just to confirm, your point is that adding 
> the (logically unnecessary) "and A.x = C.x" provides more 
> information that the optimizer can use to choose a more 
> efficient access path?
> 
> 
> 
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Wolfgang Breitling
> 
> I need some help here. How do I code a full transitive 
> closure join with the new syntax? In the traditional syntax I can say:
> 

Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions
and other information in this message that do not relate to the official
business of this company shall be understood as neither given nor endorsed
by it.

--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: