Bad exec plan when joining tables using primary keys together w/ Contains

Question

Hello all...this is something that confuzzles me....
When joining 2 tables, the exec plan shows that the domain index is first accessed, before checking if there is a record in the other table using a highly selective index.
create table users
(userid varchar2(20),
name varchar2(100),
resume clob
create table seeker
(seekerid varchar2(20),
userid varchar2(20),
jobid varchar2(20)
create index user_idx on users(userid)
create index job_resume_index on users(resume)
indextype is ctxsys.context
create unique index seeker_unik on seeker(seekerid)
create index seeker_index on seeker(jobid,userid)
then sample records where inserted, then the text index was sync'ed.
Query and Execution Plan:
select u.userid, u.name
from users u, seeker s
where s.jobid = 'HJOBP000000000218627'
and u.userid = s.userid
and contains(resume,'texas') > 1
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=72)
1 0 NESTED LOOPS (Cost=3 Card=1 Bytes=72)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'USERS' (Cost=2 Card=1
Bytes=30)
3 2 DOMAIN INDEX OF 'JOB_RESUME_INDEX' (Cost=0)
4 1 INDEX (RANGE SCAN) OF 'SEEKER_INDEX' (NON-UNIQUE) (Cost=
1 Card=1 Bytes=42)
The problem with execution plan is if the domain index returns huge number of records i.e. 40k rows, then it has to check each userid with the SEEKER table, and returns only 10 rows. I can add a hint to specify the use of the user_idx instead of the domain index to improve performance.
My question is how does the database determine when to use the domain index or to use other highly selective index with out the aid of a HINT. The trace file shows the use of "CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost and "CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost. Are these used to compute and compare the cost of each index and decide on what index to used? If so, why does it return a lower cost for domain index when the btree index is more efficient? I have all statistics gathered for all tables and indexes (inc dr$ tables and its indexes)
Thanks,
jojo

Answer 1

Hi,
What I'm pasting here is actually from Ch9 of Expert PL/SQL. It shows what happens during a select with CONTAINS. It does not include a join with another table, or an additional column in the where clause. Hope it helps.
================================================
By default, the Extensible Query Optimizer is enabled. When enabled, the Extensible Query Optimizer can determine the I/O and CPU cost associated with the CONTAINS predicate, find the cost of each call to the CONTAINS() function, and determine the selectivity of the CONTAINS predicate.
To see this in action I ran the basic select earlier. Examining the SQL trace shows the steps.
Step 1 - Determine the I/O and CPU cost of the CONTAINS() function:
--Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost(
sys.ODCIFuncInfo('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
2),
cost,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(
2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 2 – Determine the selectivity of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsSelectivity(
sys.ODCIPREDINFO('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
32),
sel,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
0,
NULL,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 3: Determine the I/O and CPU cost of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost(
sys.ODCIINDEXINFO('PLSQL',
'EXPERT_IDX',
sys.ODCICOLINFOLIST(
sys.ODCICOLINFO('PLSQL', 'DOCUMENT_REPOSITORY',
'"DOCUMENT"', 'BFILE', NULL, NULL)),
NULL,
0,
0),
50.00000000,
cost,
sys.ODCIQUERYINFO(
2,
sys.ODCIOBJECTLIST(sys.ODCIOBJECT('SCORE', 'CTXSYS'))),
sys.ODCIPREDINFO('CTXSYS', 'CONTAINS', NULL, 0),
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
1,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Note: The 50.00000000 in this last call is the selectivity retrieved from step 2.
Only after these three steps complete does the query actually get executed:
-- Available online as part of contains_trace.doc
SELECT score(1), title
FROM document_repository
WHERE CONTAINS(document, 'constitution', 1) > 0
ORDER BY 1 DESC;
This is not the end of the processing though. To retrieve the records, the $I table (the index data table) is queried as follows:
-- Available online as part of contains_trace.doc
SELECT /*+ INDEX(i) */ TOKEN_FIRST,TOKEN_LAST,TOKEN_COUNT,ROWID
FROM "PLSQL"."DR$EXPERT_IDX$I" i
WHERE TOKEN_TEXT = 'CONSTITUTION'
AND TOKEN_TYPE = 0
ORDER BY TOKEN_TEXT, TOKEN_TYPE, TOKEN_FIRST;
Note: The search term is UPPERCASE when querying against the DR$EXPERT_IDX$I table because all of the tokens are stored in uppercase by default. The original SELECT was in lowercase. This automatic conversion to uppercase allows the Text index to provide case-insensitive searching.
This query returns the following result:
TOKEN_FIRST TOKEN_LAST TOKEN_COUNT ROWID
1 2 2 AAAN54AAEAAAOvEAAo
Finally, the $R table (the rowid table) is queried.
-- Available online as part of contains_trace.doc
SELECT data
FROM "PLSQL"."DR$EXPERT_IDX$R"
WHERE row_no = 0;
Only now do I see the results of my query:
SCORE(1) TITLE
55 United States Constitution
8 Bill of Rights
Keep in mind that modifications to the query, such as the addition of other columns in the where clause or the addition of operators, will result in a different trace.
===============================