Thanks

Donatello

> why do not you want to apply the constraints, I believe the following
> solution (PK and FK mode RELY), is the only viable, right?

Sorry, but I’m not sure to understand what do you mean. Hence, if I missed you question, let me know!

In the case do you want to know how to take advantage of join elimination in case of missing (enforced) constraints, yes, AFAIK the trick with the disabled constraints marked with RELY is the only viable option.

HTH
Chris

SQL> CREATE TABLE t1 (
  2      id NUMBER NOT NULL,
  3      n NUMBER,
  4      pad VARCHAR2(4000)
  5  );

SQL> insert into t1
  2      select rownum as id, rownum+1 as n, dbms_random.string('Z', 1000) as pad 
  3      from dual 
  4      connect by level <= 100000;

SQL> CREATE TABLE t2 (
  2        id NUMBER NOT NULL,
  3        t1_id NUMBER NOT NULL,
  4        n NUMBER,
  5        pad VARCHAR2(4000)
  6  );

SQL> insert into t2
  2      select rownum as id, rownum as t1_id, rownum+1 as n, dbms_random.string('Z', 1000) as pad 
  3      from dual 
  4      connect by level <= 100000;

SQL> CREATE VIEW v AS
  2       SELECT t1.id AS t1_id, t1.n AS t1_n, t2.id AS t2_id, t2.n AS t2_n
  3       FROM t1, t2
  4       WHERE t1.id = t2.t1_id;

SQL> ALTER TABLE t1 ADD CONSTRAINT t1_pk
  2      PRIMARY KEY (id)  
  3      RELY DISABLE NOVALIDATE;

SQL> ALTER TABLE t2 ADD CONSTRAINT t2_t1_fk
  2      FOREIGN KEY (t1_id) REFERENCES t1  
  3      RELY DISABLE NOVALIDATE;

SQL> EXPLAIN PLAN FOR SELECT t2_id, t2_n FROM v;

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'all'));

---------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   100K|  1464K|  2522   (1)|
|   1 |  TABLE ACCESS FULL| T2   |   100K|  1464K|  2522   (1)|
---------------------------------------------------------------

thanks
Donatello

@Sake

> However, I’m curious, in what kind of real world situation when the “unnecessary” self-joins will occur ?

I do not have a real case to share with you. But, let’s face it, lot of databases run “strange” SQL statements ;-)

@Gary

> The optimized selects assume the constraint is in force and give a one row result based solely on t2.

That should not happen. IMO this is a bug.

@Dongkyu

First of all, thank you for the detailed feedback! BTW, I do not consider case 7 a “join elimination” technique. And that even though a join is avoided. Otherwise we should consider also query rewrite techinques being part of “join elimination”. Anyway, it’s not really important ;-)

@Timur

> the second case is an enhancement introduced in a one-off patch #7679164 for most *nix

Thanks for the information. I didn’t know it…

Cheers,
Chris

the second case is an enhancement introduced in a one-off patch #7679164 for most *nix, and is included in Win patch bundle #19

I found 7 Rules for Join Elimination in last year

1.Primary Key-Foreign Key – normal join, Starting in 10gR2
2.Primary Key-Foreign Key – ANSI join, Starting in 11gR1
3.Primary Key-Foreign Key – (semi/anti) join, Starting in 11gR1
4.Unique Index – outer join, Starting in 11gR1

Every guru knows above 4 things

5.Primary Key-Primary Key – simple self join, Starting in 11gR2
–> you ‘ve aleady mentioned

There are two more things and one simular thing
6.Primary Key-Primary Key – self join filter subsumption, Starting in 11gR2
7.Join Back Elimination – Using Bit Map Join Index, Starting in 9iR1

let me show you two things

6.Primary Key-Primary Key – self join filter subsumption
ex)
SELECT e1.employee_id, e1.salary, e1.manager_id
FROM employee e1
WHERE e1.salary > 10000
AND e1.manager_id > 100
AND e1.employee_id IN (SELECT e2.employee_id
FROM employee e2
WHERE e2.salary > 9000);

Outline Data:
/*+
…omission
ELIMINATE_JOIN(@”SEL$5DA710D3″ “E1″@”SEL$1″)
…omission
*/

*************************
Join Elimination (JE)
*************************
…omission
JE: eliminate table: EMPLOYEE (E1)
JE: Replaced column: E1.MANAGER_ID with column: E2.MANAGER_ID
JE: Replaced column: E1.SALARY with column: E2.SALARY
JE: Replaced column: E1.EMPLOYEE_ID with column: E2.EMPLOYEE_ID
JE: Replaced column: E1.SALARY with column: E2.SALARY
JE: Replaced column: E1.MANAGER_ID with column: E2.MANAGER_ID
Registered qb: SEL$CAE83587 0×88a90ea8 (JOIN REMOVED FROM QUERY BLOCK SEL$5DA710D3; SEL$5DA710D3; “E1″@”SEL$1″)

7.Join Back Elimination – Using Bit Map Join Index
ex)

CREATE BITMAP INDEX emp_join_idx_01 ON employee(d.location_id)
FROM employee e, department d
WHERE e.department_id = d.department_id;

SELECT /*+ INDEX(e emp_join_idx_01) */
COUNT (*)
FROM employee e, department d
WHERE e.department_id = d.department_id
AND d.location_id = 1700;

——————————————————+
| Id | Operation | Name |
——————————————————+
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | BITMAP CONVERSION COUNT | |
| 3 | BITMAP INDEX SINGLE VALUE | EMP_JOIN_IDX_01|
——————————————————+

Outline Data:
/*+
…omission
ELIMINATE_JOIN(@”SEL$1″ “D”@”SEL$1″)
Outline(@”SEL$1″)
BITMAP_TREE(@”SEL$1″ “E”@”SEL$1″ AND((“DEPARTMENT”.”LOCATION_ID”)))
…omission
*/

***************************************
STAR TRANSFORMATION PLANS
***************************************
Best join order so far: 2
Marked for join-back elimination: “D”@”SEL$1″
Join order[1]: EMPLOYEE[E]#0
***********************
Best so far: Table#: 0 cost: 1.0003 card: 15.2857 bytes: 45
***********************
Registered qb: SEL$DBFB62D6 0xe414820 (BITMAP JOIN INDEX JOINBACK ELIMINATION SEL$1; SEL$1; “D”@”SEL$1″)

Last, One simulat thing
be careful, It is not join-elimination
It is called Subquery Coalescing, Starting in 11gR2
ex)
SELECT /*+ QB_NAME(MAIN) */ e.employee_id, e.first_name, e.last_name
FROM employee e
WHERE e.salary > 2000
AND ( EXISTS (SELECT /*+ QB_NAME(SUB1) */ 1
FROM department d1
WHERE d1.department_id = e.department_id
AND d1.location_id = 1700)
OR EXISTS (SELECT /*+ QB_NAME(SUB2) */ 1
FROM department d2
WHERE d2.department_id = e.department_id
AND d2.department_name > ‘Accounting’)
) ;

—————————————————+
| Id | Operation | Name |
—————————————————+
| 0 | SELECT STATEMENT | |
| 1 | MERGE JOIN | |
| 2 | SORT UNIQUE | |
| 3 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT|
| 4 | INDEX FULL SCAN | DEPT_ID_PK|
| 5 | SORT JOIN | |
| 6 | TABLE ACCESS FULL | EMPLOYEE |
—————————————————+

Outline Data:
/*+
…omission
COALESCE_SQ(@”SUB2″)
Outline(@”SEL$4B4BED4E”)
COALESCE_SQ(@”SUB1″)
…omission
*/

Subquery Coalescing rewite SQL LIKE below.

SELECT /*+ QB_NAME(MAIN) */ e.employee_id, e.first_name, e.last_name
FROM employee e
WHERE e.salary > 2000
AND EXISTS (SELECT /*+ QB_NAME(SUB1) */ 1
FROM department d1
WHERE d1.department_id = e.department_id
AND (d1.location_id = 1700 OR d2.department_name > ‘Accounting’)) ;

from 10053 trace

Registered qb: SEL$4B4BED4E 0×2428950 (SUBQUERY COALESCE SUB1; SUB1)
———————
QUERY BLOCK SIGNATURE
———————
signature (): QB_NAME=SEL$4B4BED4E nbfros=1 flg=0
fro(0): flg=0 objn=73948 hint_alias=”D1″@”SUB1″

Registered qb: SEL$5DD85A06 0×2428950 (SUBQUERY COALESCE SEL$4B4BED4E; SUB2)
———————
QUERY BLOCK SIGNATURE
———————
signature (): QB_NAME=SEL$5DD85A06 nbfros=1 flg=0
fro(0): flg=0 objn=73948 hint_alias=”D1″@”SUB1″

good stuff. right?

However, I’m curious, in what kind of real world situation when the “unnecessary” self-joins will occur ?
(Besides coder mistake, of course)