Hi Jay,
Under rule based optimization deficient (outer joined) relations are always last
in the join order. In general cost based optimization will do the same, but it
is not bound to do so. For example, if T2 below is a complex view, then it
cannot be merged into the parent query because it is b
Hi Jay,
Under rule based optimization deficient (outer joined) relations are always last
in the join order. In general cost based optimization will do the same, but it
is not bound to do so. For example, if T2 below is a complex view, then it
cannot be merged into the parent query because it is b
No, I was the one who was confused when I retyped the query to send it.
It should read:
>select stuff
> from inlineview1 T0,
> inlineview2 T1,
> inlineview3 T2,
> account ac,
> phone ph
>where T0.generic_id = T1.account_id
> and T1.account_id = T2.account_i
if ac.id column is indexed for outer join to use this index this column
should be not ull or condition should be added ac.id is not null or ac.id>0
etc. It is because an index will not have rowid's for rows when this column
is null.
Alex Hillman
-Original Message-
Sent: Tuesday, April 10
I am a little confused. Is not PHONE, in this query, the one WITHOUT the +?
At 11:25 AM 4/10/01 -0800, you wrote:
>Hi all,
>
>I was just trying to figure out why in an outer join Oracle prefers to
>access the table with the (+) first. I would have thought that the table
>from which all the data
Hi all,
I was just trying to figure out why in an outer join Oracle prefers to
access the table with the (+) first. I would have thought that the table
from which all the data was coming would come first and then appropriate
rows would come from the second table with nulls being generated for
no