Как может узел в плане выполнения иметь меньшие затраты, чем его дочерний элемент?

Question

Я всегда думал, что узел в плане выполнения может быть выполнен только после того, как его дочерние элементы были выполнены, и, таким образом, общая стоимость узла должна быть больше или равна стоимости дочерних узлов. Однако это не всегда так, как в следующем примере:

Plan hash value: 2810258729

------------------------------------------------------------------------------------------------- ------------------------
| Id  | Operation                                | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------- ------------------------
|   0 | SELECT STATEMENT                         |                              |    10 |  1170 |  3871   (1)| 00:00:47 |
|*  1 |  COUNT STOPKEY                           |                              |       |       |            |          |
|   2 |   VIEW                                   |                              |    10 |  1170 |  3871   (1)| 00:00:47 |
|   3 |    VIEW                                  | V_TOP_GENRE                  |    10 |  1170 |  3871   (1)| 00:00:47 |
|   4 |     WINDOW SORT                          |                              |    10 |   890 |  3871   (1)| 00:00:47 |
|   5 |      MERGE JOIN                          |                              |    10 |   890 |  3871   (1)| 00:00:47 |
|   6 |       VIEW                               |                              |   345 | 10350 |  3867   (1)| 00:00:47 |
|   7 |        SORT GROUP BY                     |                              |   345 | 16560 |   133K  (1)| 00:26:41 |
|*  8 |         HASH JOIN                        |                              |  9627 |   451K|   133K  (1)| 00:26:41 |
|   9 |          VIEW                            |                              |  9627 |   366K|   133K  (1)| 00:26:41 |
|  10 |           SORT UNIQUE                    |                              |  9627 |   611K|   133K (51)| 00:26:41 |
|  11 |            UNION-ALL                     |                              |       |       |            |          |
|* 12 |             HASH JOIN                    |                              |  6639 |   421K| 66681   (1)| 00:13:21 |
|  13 |              INDEX FAST FULL SCAN        | T_CREATIVE_SELECTED_ADV_CREA | 28973 |   169K|     9   (0)| 00:00:01 |
|  14 |              NESTED LOOPS                |                              | 22243 |  1281K| 66671   (1)| 00:13:21 |
|  15 |               TABLE ACCESS BY INDEX ROWID| REPORT_FILTER_TIMERANGE      |     1 |    24 |     1   (0)| 00:00:01 |
|* 16 |                INDEX UNIQUE SCAN         | SYS_C0053942                 |     1 |       |     1   (0)| 00:00:01 |
|* 17 |               TABLE ACCESS FULL          | INSERTION_TV_RADIO           | 22243 |   760K| 66670   (1)| 00:13:21 |
|* 18 |             HASH JOIN                    |                              |  2988 |   189K| 66697   (1)| 00:13:21 |
|  19 |              INDEX FAST FULL SCAN        | T_CREATIVE_SELECTED_ADV_CREA | 28973 |   169K|     9   (0)| 00:00:01 |
|  20 |              NESTED LOOPS                |                              | 10010 |   576K| 66688   (1)| 00:13:21 |
|  21 |               TABLE ACCESS BY INDEX ROWID| REPORT_FILTER_TIMERANGE      |     1 |    24 |     1   (0)| 00:00:01 |
|* 22 |                INDEX UNIQUE SCAN         | SYS_C0053942                 |     1 |       |     1   (0)| 00:00:01 |
|* 23 |               TABLE ACCESS FULL          | INSERTION_TV_RADIO           | 10010 |   342K| 66687   (1)| 00:13:21 |
|  24 |          TABLE ACCESS FULL               | ASSIGNMENT_BROADCAST_GENRE   | 25135 |   220K|    20   (0)| 00:00:01 |
|* 25 |       SORT JOIN                          |                              |   345 | 10005 |     4  (25)| 00:00:01 |
|  26 |        TABLE ACCESS FULL                 | GENRE                        |   345 | 10005 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------- ------------------------


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

   1 - filter(ROWNUM<=10)
   8 - access("A"."BROADCAST_ID"="C"."BROADCAST_ID")
  12 - access("AD"."CREATIVE_ID"="A"."CREATIVE_ID")
  16 - access("B"."RANGE_NAME"='current')
  17 - filter("A"."BROADCAST_BEFORE_ID"<>(-1) AND "A"."INS_DATE">="B"."START_DATE" AND
              "A"."INS_DATE"<="B"."END_DATE")
  18 - access("AD"."CREATIVE_ID"="A"."CREATIVE_ID")
  22 - access("B"."RANGE_NAME"='current')
  23 - filter("A"."BROADCAST_AFTER_ID"<>(-1) AND "A"."BROADCAST_BEFORE_ID"<>(-1) AND
              "A"."BROADCAST_BEFORE_ID"<>"A"."BROADCAST_AFTER_ID" AND "A"."INS_DATE">="B"."START_ DATE" AND "A"."INS_DATE"<="B"."END_DATE")
  25 - access("TA"."GENRE_ID"="G"."GENRE_ID")
       filter("TA"."GENRE_ID"="G"."GENRE_ID")

Как правильно определить разницу в расходах между строками 6 и 7?

Answer 1

Вы не предоставили SQL, но у вас, вероятно, есть скалярные подзапросы в общем запросе - EXPLAIN PLAN в этом случае выводит стоимость одного выполнения подзапроса, но не знает, сколько раз он будет выполняться.

[Изменить] Я подумал, что если бы я посмотрел, я нашел бы справку Джонатана Льюиса, которая объясняет это лучше - см. http://jonathanlewis.wordpress.com/2007/10/12/scalar-subqueries/

Answer 2

Может быть, попробуйте другой инструмент (TOAD / SQL * Plus / etc), чтобы увидеть, является ли результат тем же самым (например, чтобы определить, является ли это отображением клиента или сервера)?

Все ли ваши таблицы АНАЛИЗОВАНЫ?