Slow query times with "contains" and "or"

Question

We're running Oracle 9.2.0.4 on RHEL 3
I have a simple table - "docinfo". I've create a multicolumn Text index for docinfo called "repoidx". I have five cases below with the fourth one being the most difficult to understand. I have a primary key for "docinfo" but do nott have any additional indexes on "docinfo" right now because we're still testing the design. I'm curious about what is magical about using "or" plus "contains" in the same query (case 4).
[case 1 - simple like]
select count(docid)
from sa.docinfo
where
author like '%smith%'
Elapsed: 00:00:00.02
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1468 Card=1 Bytes=15)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'DOCINFO' (Cost=1468 Card=12004 Bytes=180060)
[case 2 - simple contains]
select count(docid)
from sa.docinfo
where contains(repoidx,'facts')>0
Elapsed: 00:00:01.00
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3905 Card=1 Bytes=12)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'DOCINFO' (Cost=3905 Card=21278 Bytes=255336)
3 2 DOMAIN INDEX OF 'IDX_DOCINFO_REPOIDX' (Cost=3549)
[case 3 - simple like _and_ simple contains]
select count(docid)
from sa.docinfo
where
contains(repoidx,'facts')>0
and
author like '%smith%'
Elapsed: 00:00:00.02
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3905 Card=1 Bytes= 23)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'DOCINFO' (Cost=3905 Card=1064 Bytes=24472)
3 2 DOMAIN INDEX OF 'IDX_DOCINFO_REPOIDX' (Cost=3549)
[case 4 - simple like _or_ simple contains]
select count(docid)
from sa.docinfo
where
contains(repoidx,'facts')>0
or
author like '%smith%'
Elapsed: 00:01:37.02
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1468 Card=1 Bytes= 23)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'DOCINFO' (Cost=1468 Card=32218 Bytes=741014)
[case 5 - simple like union simple contains]
select count(docid)
from sa.docinfo
where
contains(repoidx,'facts')>0
union
select count(docid)
from sa.docinfo
where
author like '%smith%'
Elapsed: 00:00:00.04
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=5581 Card=2 Bytes= 27)
1 0 SORT (UNIQUE) (Cost=5581 Card=2 Bytes=27)
2 1 UNION-ALL
3 2 SORT (AGGREGATE) (Cost=4021 Card=1 Bytes=12)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'DOCINFO' (Cost=3905 Card=21278 Bytes=255336)
5 4 DOMAIN INDEX OF 'IDX_DOCINFO_REPOIDX' (Cost=3549)
6 2 SORT (AGGREGATE) (Cost=1560 Card=1 Bytes=15)
7 6 TABLE ACCESS (FULL) OF 'DOCINFO' (Cost=1468 Card=12004 Bytes=180060)

Answer 1

Case 1:
There is no index on author and it would not be able to use one if there was, due to the leading %, so it does a full table scan, which is still quick, since that is all there is to the query.
Case 2:
It has an index on repoidx, so it uses it and it is quick.
Case 3:
It has an index on repoidx, so it uses it. Since "and" is used, both conditions must be met. It has quckly obtained the results that match the first condition using the index, so it only has to check those rows, not every row in the table, to see if they also match the second condition.
Case 4:
Either condition may be met. It does not have an index on author, so it cannot use an index for that conditiion. Either condition can be met and it cannot duplicate the rows where both conditions are met, so it cannot use the results of one condition to check the other. So, it has to do a full table scan, in order to check every row for either condition, so it is slow.
Case 5:
select count (docid)
from   docinfo
where  contains (repoidx, 'facts') > 0
union
select count (docid)
from   docinfo
where  author like '%smith%';is not the same as:
select count (docid)
from   (select docid
        from   docinfo
        where  contains (repoidx, 'facts') > 0
        union
        select docid
        from   docinfo
        where  author like '%smith%');which is the same as case 4 and therefore just as slow. Your case 5 is just taking the union of 2 numbers, which could result in one row or two rows, depending on whether the numbers happen to match or not. Consider the following:
scott@ORA92> SELECT job, empno
  2  FROM   emp
  3  /
JOB            EMPNO
CLERK           7369
SALESMAN        7499
SALESMAN        7521
MANAGER         7566
SALESMAN        7654
MANAGER         7698
MANAGER         7782
ANALYST         7788
PRESIDENT       7839
SALESMAN        7844
CLERK           7876
CLERK           7900
ANALYST         7902
CLERK           7934
14 rows selected.
scott@ORA92> SELECT job, COUNT (empno)
  2  FROM   emp
  3  GROUP  BY job
  4  /
JOB       COUNT(EMPNO)
ANALYST              2
CLERK                4
MANAGER              3
PRESIDENT            1
SALESMAN             4
scott@ORA92> SELECT COUNT (empno)
  2  FROM   emp
  3  WHERE  job = 'SALESMAN'
  4  /
COUNT(EMPNO)
           4
scott@ORA92> SELECT COUNT (empno)
  2  FROM   emp
  3  WHERE  job = 'CLERK'
  4  /
COUNT(EMPNO)
           4
scott@ORA92> SELECT COUNT (empno)
  2  FROM   emp
  3  WHERE  job = 'SALESMAN'
  4  UNION
  5  SELECT COUNT (empno)
  6  FROM   emp
  7  WHERE  job = 'CLERK'
  8  /
COUNT(EMPNO)
           4
scott@ORA92> -- the above is the same as:
scott@ORA92> SELECT 4 FROM DUAL
  2  UNION
  3  SELECT 4 FROM DUAL
  4  /
         4
         4
scott@ORA92> -- it is not the same as:
scott@ORA92> SELECT COUNT (empno)
  2  FROM   (SELECT empno
  3            FROM   emp
  4            WHERE  job = 'SALESMAN'
  5            UNION
  6            SELECT empno
  7            FROM   emp
  8            WHERE  job = 'CLERK')
  9  /
COUNT(EMPNO)
           8
scott@ORA92> -- if the numbers are different, you get 2 rows:
scott@ORA92> SELECT COUNT (empno)
  2  FROM   emp
  3  WHERE  job = 'ANALYST'
  4  UNION
  5  SELECT COUNT (empno)
  6  FROM   emp
  7  WHERE  job = 'MANAGER'
  8  /
COUNT(EMPNO)
           2
           3
scott@ORA92> -- the above is the same as:
scott@ORA92> SELECT 2 FROM DUAL
  2  UNION
  3  SELECT 3 FROM DUAL
  4  /
         2
         2
         3
scott@ORA92> -- it is not the same as:
scott@ORA92> SELECT COUNT (empno)
  2  FROM   (SELECT empno
  3            FROM   emp
  4            WHERE  job = 'ANALYST'
  5            UNION
  6            SELECT empno
  7            FROM   emp
  8            WHERE  job = 'MANAGER')
  9  /
COUNT(EMPNO)
           5