Thanks for the comment. In “Cost Based Oracle – Fundamentals” I mentioned (without naming it) that 10g hadintroduced a new parameter to ensure that the join predicate was retained ( _optimizer_transitivity_retain, with description “retain equi-join pred upon transitive equality pred generation” ). This one goes that little bit further. It would be useful to see how many other possible transformations could be blocked by this parameter change.

SQL> explain plan for
  2  select t1.n2 , t2.n2
  3  from t1, t2
  4  where t1.n1 = :b1
  5  and t2.n1 = t1.n1
  6  /

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------
Plan hash value: 1167318051

----------------------------------------------------------------------
| Id  | Operation                    | Name  | Rows  | Bytes | Cost  |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |       |   225 |  3600 |    19 |
|*  1 |  HASH JOIN                   |       |   225 |  3600 |    19 |
|   2 |   TABLE ACCESS BY INDEX ROWID| T1    |    15 |   120 |     2 |
|*  3 |    INDEX RANGE SCAN          | T1_I1 |    15 |       |     1 |
|*  4 |   TABLE ACCESS FULL          | T2    |    15 |   120 |    15 |
----------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T2"."N1"="T1"."N1")
   3 - access("T1"."N1"=TO_NUMBER(:B1))
   4 - filter("T2"."N1"=TO_NUMBER(:B1))

Note
-----
   - cpu costing is off (consider enabling it)

22 rows selected.

As you can see, the predicate has ended up being applied to both tables.
In fact, at least in this version of Oracle – I don’t recall if it is the same for older versions, you can even replace the bind variable with a call to sys_content() and see transitive closure; the same would apply with a call to a deterministic function that returns a constant.

FYI: in 11.2.0.3, the transitive closure effect of removing the join predicate and replacing it with filters for each table can be prevented with

“_optimizer_filter_pushdown” = false

So instead of:

FPD: Considering simple filter push in query block SEL$1 (#0)
“O”.”CUSTOMER_ID”=”C”.”CUSTOMER_ID” AND “C”.”CUSTOMER_ID”=:B1
try to generate transitive predicate from check constraints for query block SEL$1 (#0)
finally: “O”.”CUSTOMER_ID”=:B1 AND “C”.”CUSTOMER_ID”=:B2

it is disabled:
FPD: Disabled by parameter

Best regards,
Martin

“Transitive closure is relevant only if there are some constants in the mixture” , you say

Does this mean that it can’t be an issue if cursor_sharing = FORCE or SIMILAR ?

If you have a general problem with an entire class of queries that behaved in version “X” but not in version “Y” then you could try running the 10053 against one of them after setting “optimizer_features_enable” to each of the two values in turn. You can then compare the section about optimizer environment values to see if you can spot the most likely parameter that is causing the change.

_optimizer_transitivity_retain = false
This handles the case of
if a = b and b = c then a = c.
Earlier versions of Oracle would take:
where a = b and b = c
and change it to something like
where a = b and a = c
discarding the b=c
in newer versions of Oracle the new predicate is generated and the old predicate is retained – giving 3 predicates – if this parameter is set to true.

_push_join_predicate = false
This parameter is not about general predicat move around, it relates to Oracle ability to push join predicates into non-mergeable views; potentially allowing a large hash join to become a nested loop approach.

I thought this would avoid any push join, but still it’s doing push join.

Because It’s trying possiblities in QUERY TRANFORMATION phase and then rejecting predicates. I am thinking to disable query transformation, but trying to find out how to do that.

Thanks

~ Keyur