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