Subquery execution plan issue

Question

Hi All,
Oracle v11.2.0.2
I have a SELECT query which executes in less than a second and selects few records.
Now, if I put this SELECT query in IN clause of a DELETE command, that takes ages (even when DELETE is done using its primary key).
See below query and execution plan.
Here is the SELECT query
SQL> SELECT   ITEM_ID
  2                         FROM   APP_OWNER.TABLE1
  3                        WHERE   COLUMN1 = 'SomeValue1234'
  4                                OR (COLUMN1 LIKE 'SomeValue1234%'
  5                                    AND REGEXP_LIKE (
  6                                          COLUMN1,
  7                                          '^SomeValue1234[A-Z]{3}[0-9]{5}$'
  8  ));
   ITEM_ID
  74206192
1 row selected.
Elapsed: 00:00:40.87
Execution Plan
Plan hash value: 3153606419
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |             |     2 |    38 |     7   (0)| 00:00:01 |
|   1 |  CONCATENATION     |             |       |       |            |          |
|*  2 |   INDEX RANGE SCAN | PK_TABLE1   |     1 |    19 |     4   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| PK_TABLE1   |     1 |    19 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COLUMN1" LIKE 'SomeValue1234%')
       filter("COLUMN1" LIKE 'SomeValue1234%' AND  REGEXP_LIKE
              ("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$'))
   3 - access("COLUMN1"='SomeValue1234')
       filter(LNNVL("COLUMN1" LIKE 'SomeValue1234%') OR LNNVL(
              REGEXP_LIKE ("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$')))
Statistics
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
        348  bytes sent via SQL*Net to client
        360  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processedNow see the DELETE command. ITEM_ID is the primary key for TABLE2
SQL> delete from TABLE2 where ITEM_ID in (
  2  SELECT   ITEM_ID
  3                         FROM   APP_OWNER.TABLE1
  4                        WHERE   COLUMN1 = 'SomeValue1234'
  5                                OR (COLUMN1 LIKE 'SomeValue1234%'
  6                                    AND REGEXP_LIKE (
  7                                          COLUMN1,
  8                                          '^SomeValue1234[A-Z]{3}[0-9]{5}$'
  9  ))
10  );
1 row deleted.
Elapsed: 00:02:12.98
Execution Plan
Plan hash value: 173781921
| Id  | Operation               | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | DELETE STATEMENT        |                             |     4 |   228 | 63490   (2)| 00:12:42 |
|   1 |  DELETE                 | TABLE2                      |       |       |            |          |
|   2 |   NESTED LOOPS          |                             |     4 |   228 | 63490   (2)| 00:12:42 |
|   3 |    SORT UNIQUE          |                             |     1 |    19 | 63487   (2)| 00:12:42 |
|*  4 |     INDEX FAST FULL SCAN| I_TABLE1_3                  |     1 |    19 | 63487   (2)| 00:12:42 |
|*  5 |    INDEX RANGE SCAN     | PK_TABLE2                   |     7 |   266 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("COLUMN1"='SomeValue1234' OR "COLUMN1" LIKE 'SomeValue1234%' AND
              REGEXP_LIKE ("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$'))
   5 - access("ITEM_ID"="ITEM_ID")
Statistics
          1  recursive calls
          5  db block gets
     227145  consistent gets
     167023  physical reads
        752  redo size
        765  bytes sent via SQL*Net to client
       1255  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          1  rows processedWhat can be the issue here?
I tried NO_UNNEST hint, which made difference, but still the DELETE was taking around a minute (instead of 2 minutes), but that is way more than that sub-second response.
Thanks in advance

Answer 1

rahulras wrote:
SQL> delete from TABLE2 where ITEM_ID in (
2  SELECT   ITEM_ID
3                         FROM   APP_OWNER.TABLE1
4                        WHERE   COLUMN1 = 'SomeValue1234'
5                                OR (COLUMN1 LIKE 'SomeValue1234%'
6                                    AND REGEXP_LIKE (
7                                          COLUMN1,
8                                          '^SomeValue1234[A-Z]{3}[0-9]{5}$'
9  ))
10  );
The optimizer will transform this delete statement into something like:
delete from table2 where rowid in (
    select t2.rowid
    from
        table2 t2,
        table1 t1
    where
            t1.itemid = t2.itemid  
    and     (t1.column1 =  etc.... )
)With the standalone subquery against t1 the optimizer has been a little clever with the concatenation operation, but it looks as if there is something about this transformed join that makes it impossible for the concatenation mechanism to be used. I'd also have to guess that something about the way the transformation has happened has made Oracle "lose" the PK index. As I said in another thread a few minutes ago, I don't usually look at 10053 trace files to solve optimizer problems - but this is the second one today where I'd start looking at the trace if it were my problem.
You could try rewriting the query in this explicit join and select rowid form - that way you could always force the optimizer into the right path through table1. It's probably also possible to hint the original to make the expected path appear, but since the thing you hint and the thing that Oracle optimises are so different it might turn out to be a little difficult. I'd suggest raising an SR with Oracle.
Regards
Jonathan Lewis