Oracle LEFT JOIN View performance -


i have 2 tables, aren't large tables. have created view based on tables

select    tab_a.id id,    tab_a.name name  tablea tab_a  union  select    tab_b.id id,    tab_b.name name  tableb tab_b 

after all, have third table, lets call tablemain fields:

tablemain.id, tablemain.status, tablemain.viewid

viewid exists join view

final select like

select tablemain.id   tablemain   left outer join view on tablemain.viewid=view.id 

and join very slow on view.

its fast if join directly tablea or tableb, not when using view.

it fast if use view.name in select

select tablemain.id, view.name   tablemain   left outer join view on tablemain.viewid=view.id 

not sure why view join working fast if use view field in select,

and how make view join fast without it.

posting plans:

good plan (using view.name in select)

select tablemain.id, view.name   tablemain   left outer join view on tablemain.viewid=view.id    | id  | operation            | name           | rows  | bytes | cost (%cpu)| time     | |   0 | select statement     |                |   220k|   440m|    50   (4)| 00:00:01 | |*  1 |  hash join outer     |                |   220k|   440m|    50   (4)| 00:00:01 | |   2 |   table access full  | **tablemain**  | 19796 |  1527k|    42   (0)| 00:00:01 | |   3 |   view               | ***view***     |  1115 |  2194k|     6   (0)| 00:00:01 | |   4 |    union-all         |                |       |       |            |          | |   5 |     table access full| **tablea**     |   818 |  1609k|     3   (0)| 00:00:01 | |*  6 |     table access full| **tableb**     |   297 |  5346 |     3   (0)| 00:00:01 | 

bad plan (no view.name in select)

select tablemain.id   tablemain   left outer join view on tablemain.viewid=view.id  | id  | operation                     | name            | rows  | bytes | cost (%cpu)| time     |    tq  |in-out| pq distrib | |   0 | select statement              |                 |   220k|    19m|    51   (6)| 00:00:01 |        |      |            | |   1 |  px coordinator               |                 |       |       |            |          |        |      |            | |   2 |   px send qc (random)         | :tq10003        |   220k|    19m|    51   (6)| 00:00:01 |  q1,03 | p->s | qc (rand)  | |*  3 |    hash join right outer      |                 |   220k|    19m|    51   (6)| 00:00:01 |  q1,03 | pcwp |            | |   4 |     px receive                |                 |  1115 | 14495 |     6   (0)| 00:00:01 |  q1,03 | pcwp |            | |   5 |      px send hash             | :tq10002        |  1115 | 14495 |     6   (0)| 00:00:01 |  q1,02 | p->p | hash       | |   6 |       buffer sort             |                 |   220k|    19m|            |          |  q1,02 | pcwp |            | |   7 |        view                   | ***view***      |  1115 | 14495 |     6   (0)| 00:00:01 |  q1,02 | pcwp |            | |   8 |         union-all             |                 |       |       |            |          |  q1,02 | pcwp |            | |   9 |          px block iterator    |                 |   818 | 10634 |     3   (0)| 00:00:01 |  q1,02 | pcwc |            | |  10 |           index fast full scan| ***tablea_pk*** |   818 | 10634 |     3   (0)| 00:00:01 |  q1,02 | pcwp |            | |  11 |          buffer sort          |                 |       |       |            |          |  q1,02 | pcwc |            | |  12 |           px receive          |                 |   297 |  2079 |     3   (0)| 00:00:01 |  q1,02 | pcwp |            | |  13 |            px send round-robin| :tq10000        |   297 |  2079 |     3   (0)| 00:00:01 |        | s->p | rnd-robin  | |* 14 |             table access full | **tableb**      |   297 |  2079 |     3   (0)| 00:00:01 |        |      |            | |  15 |     buffer sort               |                 |       |       |            |          |  q1,03 | pcwc |            | |  16 |      px receive               |                 | 19796 |  1527k|    42   (0)| 00:00:01 |  q1,03 | pcwp |            | |  17 |       px send hash            | :tq10001        | 19796 |  1527k|    42   (0)| 00:00:01 |        | s->p | hash       | |  18 |        table access full      | **tablemain**   | 19796 |  1527k|    42   (0)| 00:00:01 |        |      |            | 

why big difference?

something forcing parallelism. view have hints? there type of plan management happening query? example, there outline, sql plan management, or profile setup on bad query? may able find out adding note section of explain plan. if i'm right, there in 1 of execution plans:

note -----    - sql plan baseline "sql_plan_01yu884fpund494ecae5c" used statement 

also define "very slow". if query runs in 0.01 seconds , bad query runs in 2 seconds, difference may because of overhead of parallelism. if query tuned environment larger data may want keep bad plan anyway - may run better in production.


Comments

Popular posts from this blog

apache - Remove .php and add trailing slash in url using htaccess not loading css -

javascript - jQuery show full size image on click -