Hi all,
First, thanks to the developers for a great piece of software.
I am having difficulty getting an xquery on a large database to run using
indexed attributes when a "join" idiom is used. I have a large basex
database, with multiple documents. One of those contains <rs> elements as
shown below, where the @corresp attribute contains values which are
identical to the @key attribute on <person> elements, which live in
multiple separate files:
<personGrp type="match:policeNum+ship" size="3"><persName>
<rs corresp="c23a2866">Corper, Jno (Pn:1000C)...</rs>
<rs corresp="dlm18192024">Corper, John (Pn:1000C)...</rs>
<rs corresp="c31a31061000" >Corper, Jno (Pn:1000CC)...</rs>
</persName></personGrp>
I know indexes have been built as xpaths like this are lightening quick:
//person[@key="c23a2866"]
or
//rs[@corresp="dlm18192024"]
But when I do this, it is glacial (nearly 1 minute):
EG(A)
for $rs in //rs[@corresp="c31a31061000"]/../..//rs
let $keyval := data($rs/@corresp)
return //person[@key=$keyval]
I am using BaseX6.jar on XP. When I look at the query plan, the ONLY time
the attribute index used is on the //rs[@corresp="c31a31061000"] part.
I can get it to run fast and return the 3 matched <person> elements using
the attribute index using basex:eval, like this:
EG(B)
for $rs in data(//rs[@corresp="c31a31061000"]/../..//rs/@corresp)
let $s := concat("//person[@key='",$rs,"']")
return basex:eval($s)
So rather than execute this query asa "join" -- a manner which seem
widespread in the xquery world -- I must manually build and execute each
//person[@key='string'] request "manually" to get basex to use its
attribute index. Whilst this works, it seems a rather strange idiom to
have to employ, and locks my queries into basex.
Is the behaviour of EG(A) by design, or is it a bug that the query
optimizer is failing to recognise it can use the attribute index on the
//person[@key=$keyval] part?
Any guidance much appreciated.
Best wishes to all,
Sandra.