Hi France,
check out the info window of the GUI in a test-run it will tell.
Anyway I think that if the database name is in a declared variable it should defintely be able to grasp the index.
If $dbname is passed into another function as a function parameter then it could be that the info for accessing a proper index is lost. Need to check with inlining though....
On way around this that I've found is to insulate the usually small part of the predicate that applies to indexing and compose an xquery:eval for executing it with the $dbname sculpted into it. Usually the overhead is largely covered by the gain in DB access time.

Something like:
    xquery:eval("declare variable $input as xs:string external; db:open('" || $lang || "')/*[id=$input]", map{ "input" : "searchedid"})

Another case that I could experien is that if you use fn:matches instead of = in a predicate, the optimizer also gets puzzled and is not able to exploit the index.
Wonder if for these cases there could be an improvement too.

Ciao,
M.

On 20/10/2017 14:21, France Baril wrote:
Hi, 

We are working hard right now on performance issues. I just read this about an upcoming release:

Enforce Rewritings

In various cases, existing index structures will not be utilized by the query optimizer. This is usually the case if the name of the database is not a static string (e.g., because it is bound to a variable or passed on as argument of a function call). Furthermore, several candidates for index rewritings may exist, and the query optimizer may decide for a rewriting that turns out to be suboptimal.


I'm not sure I read it properly so I would like to confirm my understanding:

In our code, all our db accesses are in a format like this: db:open($lang)/*[@id='...']. Does the fact that the db name is $lang, a variable, mean that we have been working without the optimizer all this time and therefore that this new feature is there for people like us?

Thanks!

--
France Baril
Architecte documentaire / Documentation architect
france.baril@architextus.com