Any room for improvement for this query? Explain Plan attached.

Question

Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??
select sum(CONF
             when (cd.actl_qty - cd.total_alloc_qty - lsd.Q < 0) then
              0
             else
              cd.actl_qty - cd.total_alloc_qty - lsd.Q
           end)
  from (select sum(reqd_qty) as Q, ITEM_ID as ITEM
          from SHIP_DTL SD
         where exists (select 1
                  from CONF_dtl
                 where CONF_nbr = '1'
                   and ITEM_id = SD.ITEM_id)
         group by ITEM_id) lsd,
       CONF_dtl cd
where lsd.ITEM = cd.ITEM_id
   and cd.CONF_nbr = '1'Total number of rows in the tables involved
select count(*) from CONF_DTL;
  COUNT(*)
   1785889
select count(*) from shp_dtl;
  COUNT(*)
    286675
  Explain Plan
PLAN_TABLE_OUTPUT
Plan hash value: 2325658044
| Id  | Operation                           | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                    |     1 |    39 |     4  (25)| 00:00:01 |
|   1 |  SORT AGGREGATE                     |                    |     1 |    39 |            |          |
|   2 |   VIEW                              |                    |     1 |    39 |     4  (25)| 00:00:01 |
|   3 |    HASH GROUP BY                    |                    |     1 |   117 |     4  (25)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID     | SHIP_DTL           |     1 |    15 |     1   (0)| 00:00:01
|   5 |      NESTED LOOPS                   |                    |     1 |   117 |     3   (0)| 00:00:01 |
|   6 |       MERGE JOIN CARTESIAN          |                    |     1 |   102 |     2   (0)| 00:00:01 |
|   7 |        TABLE ACCESS BY INDEX ROWID  | CONF_DTL           |     1 |    70 |     1   (0)| 00:00:01 |
|*  8 |         INDEX RANGE SCAN            | PK_CONF_DTL        |     1 |       |     1   (0)| 00:00:01 |
|   9 |        BUFFER SORT                  |                    |     1 |    32 |     1   (0)| 00:00:01 |
|  10 |         SORT UNIQUE                 |                    |     1 |    32 |     1   (0)| 00:00:01 |
|  11 |          TABLE ACCESS BY INDEX ROWID| CONF_DTL           |     1 |    32 |     1   (0)| 00:00:01 |
|* 12 |           INDEX RANGE SCAN          | PK_CONF_DTL        |     1 |       |     1   (0)| 00:00:01 |
|* 13 |       INDEX RANGE SCAN              | SHIP_DTL_IND_6 |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   8 - access("CD"."CONF_NBR"='1')
  12 - access("CONF_NBR"='1')
  13 - access("ITEM_ID"="SD"."ITEM_ID")
       filter("ITEM_ID"="CD"."ITEM_ID")

Answer 1

Citizen_2 wrote:
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??You say that the table stats are up-to-date, but is the following assumption of the optimizer correct:
select count(*)
from CONF_dtl
where CONF_nbr = '1';Does this query return a count of 1? I doubt that, but that's what Oracle estimates in the EXPLAIN PLAN output. Based on that assumption you get a cartesian join between the two CONF_DTL table instances, and the result - which is still expected to be one row at most - is then joined to the SHIP_DTL table using a NESTED LOOP.
If above assumption is incorrect, the number of rows generated by the cartesian join can be tremendous rendering the NESTED LOOP operation quite inefficient.
You can verify this by using the DBMS_XPLAN.DISPLAY_CURSOR function together with the GATHER_PLAN_STATISTICS hint, if you're already on 10g or later.
For more information regarding the DISPLAY_CURSOR function, see e.g. here: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
It will show you the actual cardinalities compared to the estimated cardinalities.
If the estimate of the optimizer is incorrect, you should find out why. There still might be some issues with the statistics, since this is most obvious reason for incorrect estimates.
Are your index statistics up-to-date?
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/