XMLIndex performance regarding // (any descendant)

Question

The following is my scenario:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
create table t1 (ID NUMBER(19) NOT NULL, XMLDATA XMLType) xmltype column "XMLDATA" STORE AS BINARY XML;
-- insert 50916 rows of XML documents into t1
create index IDX_7 on t1(XMLDATA) indextype is xdb.xmlindex PARAMETERS ( 'PATHS ( INCLUDE (//FIELD_1_2))' );
Query 1:
SQL> SELECT /*+ NO_XMLINDEX_REWRITE */ COUNT(ID) FROM T1 Z WHERE Z.XMLDATA.EXISTSNODE('//FIELD_1_2') = 1;
3622
Elapsed: 00:00:01.71
Access Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2002 | 246 (3)| 00:00:03 |
| 1 | SORT AGGREGATE | | 1 | 2002 | | |
|* 2 | TABLE ACCESS FULL| T1 | 59765 | 114M| 246 (3)| 00:00:03 |
Predicate Information (identified by operation id):
2 - filter(EXISTSNODE(SYS_MAKEXML(0,"Z"."SYS_NC00004$"),'//FIELD_1_2')=1)
Query 2:
SQL> SELECT COUNT(ID) FROM T1 Z WHERE Z.XMLDATA.EXISTSNODE('//FIELD_1_2') = 1;
3622
Elapsed: 00:01:20.59
Access Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 12 | 109K (1)| 00:21:57 |
| 1 | SORT AGGREGATE | | 1 | 12 | | |
|* 2 | FILTER | | | | | |
| 3 | TABLE ACCESS FULL | T1 | 59765 | 700K| 239 (1)| 00:00:03 |
| 4 | NESTED LOOPS | | | | | |
| 5 | NESTED LOOPS | | 1 | 2028 | 2 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| X$PT1MP1MWL3978FCE0G24J0CM85AM | 1 | 1008 | 0 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | X$PR1MP1MWL3978FCE0G24J0CM85AM | 1 | | 0 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | SYS70559_IDX_7_PATHID_IX | 1 | | 1 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | SYS70559_IDX_7_PATH_TABLE | 1 | 1020 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "SCHEMA"."SYS70559_IDX_7_PATH_TABLE"
"SYS_P0","XDB"."X$PT1MP1MWL3978FCE0G24J0CM85AM" "SYS_PT_SUFFIX_2" WHERE
SYS_PATH_REVERSE("PATH")<HEXTORAW('0269C9FF') AND SYS_PATH_REVERSE("PATH")>=HEXTORAW('0269C9') AND
"SYS_P0"."RID"=:B1 AND "SYS_P0"."PATHID"="ID" AND SYS_XMLI_LOC_ISNODE("SYS_P0"."LOCATOR")=1))
7 - access(SYS_PATH_REVERSE("PATH")>=HEXTORAW('0269C9') AND
SYS_PATH_REVERSE("PATH")<HEXTORAW('0269C9FF') )
8 - access("SYS_P0"."PATHID"="ID" AND "SYS_P0"."RID"=:B1)
9 - filter(SYS_XMLI_LOC_ISNODE("SYS_P0"."LOCATOR")=1)
Query 1 suppresses the use of the XMLIndex IDX_7, while Query 2 makes use of IDX_7. It seems better to run with the use of XMLIndex in this case.
Why is the cost of Query 2 so much greater than Query 1 when the XMLIndex is actually used?
Thanks.
P.

Answer 1

Yes, I created statistics using DBMS_STATS.GATHER_INDEX_STATS.
If you look at the costs on line 1, it's Query 1 (246) vs Query 2 (107K). It's a huge difference.
I have to use //FIELD_1_2 in the query since I don't know where FIELD_1_2 is exactly in these documents. There are multiple XML schemas (not registered though) for this XMLType column.
Let's remove /*+ NO_XMLINDEX_REWRITE */ from Query 1, then Query 1 and Query 2 are the same. The optimizer chooses a different plan depending on if IDX_7 exists or not. If IDX_7 is not created, the performance for Query 1 is observed, otherwise, the performance for Query 2 is observed.
I also tried another path subsetting in the XMLIndex:
create index IDX_8 on t1(XMLDATA) indextype is xdb.xmlindex PARAMETERS ( 'PATHS ( INCLUDE (/*/FIELDS/FIELD_1/FIELD_1_2))' );
Query 3:
SELECT COUNT(ID) FROM T1 Z WHERE Z.XMLDATA.EXISTSNODE('/*/FIELDS/FIELD_1/FIELD_1_2') = 1;
Query 3 shows slower performance in the same manner compared to running the same query without IDX_8 created.
Query 4:
SELECT COUNT(ID) FROM T1 Z WHERE Z.XMLDATA.EXISTSNODE('/SPEC_47/FIELDS/FIELD_1/FIELD_1_2') = 1;
Query 4 runs much faster with the IDX_8 created than without it.
Let me ask the question differently. What can I do to improve the performance of the following query?
SELECT COUNT(ID) FROM T1 Z WHERE Z.XMLDATA.EXISTSNODE('//FIELD_1_2') = 1;
My attempts so far to create an XMLIndex with different path subsetting on the XMLDATA column actually caused the query to run slower instead of faster.
Thanks.
P.