Here’s a gem – which I will have to write up as a proper blog when I get the time: if the primary key is deferrable, you can create duplicate rows in the parent table (temporarily), which should duplicate data in the join; but the optimizer doesn’t notice when the constraint has been deferred and allows join elimination to take place: so you can get results that are arguably wrong when you defer a primary key.

Here’s a cut-n-paste from a session running 11.2.0.2:

SQL> set autotrace on explain
SQL> select  chi.name from child chi , parent par where par.id = chi.id_p;

NAME
----------
Simon
Sally
Jack
Jill

4 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2406669797

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |     4 |    36 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| CHILD |     4 |    36 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   1 - filter("CHI"."ID_P" IS NOT NULL)

SQL> select  /*+ no_eliminate_join(par) */ chi.name from child chi , parent par where par.id = chi.id_p;

NAME
----------
Simon
Simon
Sally
Sally
Jack
Jill

6 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1687613841

-----------------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     4 |    48 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |        |     4 |    48 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| CHILD  |     4 |    36 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | PAR_PK |     1 |     3 |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   3 - access("PAR"."ID"="CHI"."ID_P")

SQL> spool off

SQL>

When we disable join elimination the result changes.
The parent id for Sally and Simon exists twice in the parent table, and it’s legal for it to exist twice because I’ve made the primary key constraint on parent deferrable and deferred it.

becuase not only have you come up with a list of interesting options.. you are now actually going to test them.

all I have to say is… “Well done that man!”