Too many nested loops in execution plan?

Question

Hi,
i wonder about execution plan not indicating that access to some tables (for join) is in parallel.
Please see this example:
------------------------ snip ------------------------------------
drop table test_a1;
drop table test_a2;
drop table test_b;
drop table test_c;
drop table test_d;
create table test_a1 (
x number,
y number,
z number);
create unique index testa1_pk on test_a1 (x);
create table test_a2 (
x number,
y number,
z number);
create unique index testa2_pk on test_a2 (x);
create table test_b (
x number,
y number,
z number);
create unique index testb_pk on test_b (y);
create table test_c (
x number,
y number,
z number);
create unique index testc_pk on test_b (z);
create table test_d (
x number,
y number,
z number);
create unique index testd_pk on test_d (y);
select
a1.x a1_x,
a1.y a1_y,
a1.z a1_z,
a2.x a2_x,
a2.y a2_y,
a2.z a2_z,
b.x b_x,
b.y b_y,
b.z b_z,
c.x c_x,
c.y c_y,
c.z c_z,
d.x d_x,
d.y d_y,
d.z d_z
from test_a1 a1, test_a2 a2, test_b b, test_c c, test_d d
where a1.x = 100
and a2.x = 200
and b.y = a1.y
and c.z = b.z
and d.y = a1.y;
------------------------ snap ------------------------------------
The execution plan goes like this:
Select Stmt
     nested loops
          nested loops
               nested loops
                    nested loops
                         table access
                              index
                                   access predicate
                                        a2.x = 200
                         table access
                              index
                                   access predicate
                                        a1.x = 100
                    table access
                         index
                              access predicate
                                   d.y = a1.y
               table access
                    index
                         access predicate
                              b.y = a1.y
          table acess
               index
                    acess predicate
                         c.z = b.z
Access to tables a1 and a2 is on the same level (in parallel - i guess).
However, why isn't access to table d and b on the same level?
Both depend on a1. So no need to execute one after the other (no inter-dependency).
Maybe i have just wrong expectation to the output of the execution plan(?!)
- many thanks!
best regards,
Frank

Answer 1

Preservation of identation and spacing is invaluable when it comes to reading an explain plan.
| Id  | Operation                       | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |           |     1 |   195 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                   |           |     1 |   195 |     2   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                  |           |     1 |   156 |     0   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                 |           |     1 |   117 |     0   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                |           |     1 |    78 |     0   (0)| 00:00:01 |
|   5 |      TABLE ACCESS BY INDEX ROWID| TEST_A2   |     1 |    39 |     0   (0)| 00:00:01 |
|*  6 |       INDEX UNIQUE SCAN         | TESTA2_PK |     1 |       |     0   (0)| 00:00:01 |
|   7 |      TABLE ACCESS BY INDEX ROWID| TEST_A1   |     1 |    39 |     0   (0)| 00:00:01 |
|*  8 |       INDEX UNIQUE SCAN         | TESTA1_PK |     1 |       |     0   (0)| 00:00:01 |
|   9 |     TABLE ACCESS BY INDEX ROWID | TEST_D    |    82 |  3198 |     0   (0)| 00:00:01 |
|* 10 |      INDEX UNIQUE SCAN          | TESTD_PK  |     1 |       |     0   (0)| 00:00:01 |
|  11 |    TABLE ACCESS BY INDEX ROWID  | TEST_B    |    82 |  3198 |     0   (0)| 00:00:01 |
|* 12 |     INDEX UNIQUE SCAN           | TESTB_PK  |     1 |       |     0   (0)| 00:00:01 |
|* 13 |   TABLE ACCESS FULL             | TEST_C    |     1 |    39 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   6 - access("A2"."X"=200)
   8 - access("A1"."X"=100)
  10 - access("D"."Y"="A1"."Y")
  12 - access("B"."Y"="A1"."Y")
  13 - filter("C"."Z"="B"."Z")
Access to tables a1 and a2 is on the same level (in parallel - i guess).
Maybe i have just wrong expectation to the output of the execution plan(?!)You guess wrong, there's nothing parallel going on here.
Execution plan is a tree of parent-child operations.
For example, the NESTED LOOP at operation 4 has two children @ 5 and 7.
Both of these operations- 5 & 7 - have a single child operation.
The execution tree starts with operation 6, using the TESTA2_PK index to identify rows where A2.X=100.
From this list of rowids, we go to the table TEST_A2 operation 5.
The rows from operation five feed into the NESTED LOOP - operation 4.
For each of these rows, we go to TEST_A1 via the index TEST_A1_PK for rows where A1.X=100.
This is really a cartesian join because there's no join condition between the two tables.
etc, etc, etc
Three things in particular to point out.
Firstly, that nothing joins to A2. So there will be a cartesian product - i.e. for every row in the result set between the joined tables A1, B, C and D, these will be multiplied by the number of rows returned by the the A2 rowsource.
Secondly, when everything has got one or zero rows (or the optimizer thinks that it's one or zero rows), you can get very different plans from when there are known/thought to be more rows.
Both depend on a1. So no need to execute one after the other (no inter-dependency).Thirdly, in terms of isolated join operations (ignoring A2 and C for the moment), A1 cannot join to B and D at the same time, you can either join A1 to B and then join the result of that to D, or join A1 to D then B, which is what you've got in your plan (well, actually we have A2 joined to A1 then the result of that joined to D and then the result of that to B).
Edited by: Dom Brooks on Jul 6, 2011 4:07 PM
Corrected typo