Nah, optimization is tricksy.
True. Both for the optimizer and the developer. I can spot two indicators for …
db:open($rkDatabase)/doc-where-used-index/where-used-entry/@key[xs:integer(.) eq 9151416]
… not being rewritten for index access:
• If $rkDatabase is not static, it won’t be possible at compile time to check if the database contains the required index. • BaseX has no numeric index (not yet [1]), which is why the predicate can’t be rewritten.
Queries of the following pattern …
db:open('database')/doc-where-used-index/where-used-entry/@key[. eq '9151416']
… should definitely be optimized.
It’s sometimes possible to enforce the use of an index [2], but to simplify things, it’s just fine to explicitly address the index via db:text and db:attribute.
We have listed some more examples for index rewritings in our documentation [3]. I’ll need to extend the compilation, as various more rewriting patterns were implemented since then. For example, both '=' and 'eq' will now be rewritten if we can see at compile time that the rewriting of 'eq' won’t ignore errors that might be raised in its original form (more than single items to be compared; invalid input types; …).
[1] https://github.com/BaseXdb/basex/issues/2069 [2] https://docs.basex.org/wiki/Indexes#Enforce_Rewritings [3] https://docs.basex.org/wiki/XQuery_Optimizations#Index_Rewritings