Basic Indexing - eXist: A NoSQL Database and Application Development Platform - page 280

When you have an index of the xs:double data type, make sure
your queries actually use doubles. Don't write //Article[@price
gt 100] , but //Article[@price gt 100.0] .
• The query must not depend on the current context item.
For instance, a range index on id attributes will not be used in queries like //
Article[@id eq ../@refid] .
Indexes of the xs:string type are also used for queries that include the XPath func‐
tions contains , starts-with , and ends-with . However, substring searches like this
are not very efficient with a range index. If you do this frequently, use an NGram
index instead (and don't forget to use the special ngram extension functions discussed
in the next section to exploit those indexes).
When you're using range indexes, if you perform a query over
multiple collections and not all collections are indexed, or they are
in different indexes, eXist takes the first available index and only
uses this. Matches outside this index are ignored.
For instance, assume you have a range index defined on collec‐
tion /db/myapp/a but not on /db/myapp/b . Performing a query
over collection('/db/myapp') will return matches from /db/
myapp/a only!
Using the NGram Indexes
NGram indexes are not applied automatically in general comparisons; instead, you
need to use the functions from the ngram extension module to exploit them.
For instance, assume there is an NGram index on Text elements. An NGram query
for 'eXist indexes' might look like this:
// Text [ ngram:contains (., 'eXist indexes' )]
Remember that NGram indexes are case-insensitive. This means
that all ngram extension functions are case-insensitive too, in con‐
trast to their XPath counterparts!
The ngram extension module includes the following functions:
ngram:contains , ngram:ends-with , ngram:starts-with
These work the same way as their XPath counterparts (albeit case-insensitive).