Why is DBXML doing a table scan on this query?

Question

I loaded a database with about 610 documents, each contains about 5000 elements of the form:
<locations><location><id>100</id> ... </location> <location><id>200</id> ... </location> ... </locations>
The size of my dbxml file is about 16G. I create this with all default settings, except that I set auto-indexing off, and added 3 indexes, listed here:
dbxml> listIndexes
Index: unique-edge-element-equality-string for node {}:id
Index: edge-element-presence-none for node {}:location
Index: node-element-presence-none for node {}:locations
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
4 indexes found.
I am performing the following query:
dbxml> query 'for $location in (collection("CitySearch.dbxml")/locations/location[id = 41400]) return $location'
This has the following query plan:
dbxml> queryPlan 'for $location in (collection("CitySearch.dbxml")/locations/location[id = 41400]) return $location'
<XQuery>
<Return>
<ForTuple uri="" name="location">
<ContextTuple/>
<QueryPlanToAST>
<ParentOfChildJoinQP>
<ValueFilterQP comparison="eq" general="true">
<PresenceQP container="CitySearch.dbxml" index="unique-edge-element-equality-string" operation="prefix" child="id"/>
<NumericLiteral value="4.140E4" typeuri="http://www.w3.org/2001/XMLSchema" typename="integer"/>
</ValueFilterQP>
<ChildJoinQP>
<NodePredicateFilterQP uri="" name="#tmp0">
<PresenceQP container="CitySearch.dbxml" index="node-element-presence-none" operation="eq" child="locations"/>
<LevelFilterQP>
<VariableQP name="#tmp0"/>
</LevelFilterQP>
</NodePredicateFilterQP>
<PresenceQP container="CitySearch.dbxml" index="edge-element-presence-none" operation="eq" parent="locations" child="location"/>
</ChildJoinQP>
</ParentOfChildJoinQP>
</QueryPlanToAST>
</ForTuple>
<QueryPlanToAST>
<VariableQP name="location"/>
</QueryPlanToAST>
</Return>
</XQuery>
When I run the query, it is very clearly performing a table scan, the query takes about 10 minutes to run (argh!!) and the disk is read for the length of the query. Why is this doing a table scan, and what can I do to make this a simple, direct node access?
Andrew

Answer 1

Hi George,
I took a subset of my data set, and left auto indexing on to see what the query plan would be, then I duplicated the index being used in my larger data set with auto indexing off. The problem with leaving auto indexing on for the entire data set was the apparent size of the file: with just the single index, the file was about 17G, with auto indexing on, it was climbing over 30G (with 40 indices, I didn't include all of the tags in my original post) when I killed it. Further data load was taking forever, it is much faster with auto indexing off and then add the single index.