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.