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.