In part 1, we saw how to configure a path range index and use cts:values() to retrieve all the values from that index. In this installment, we'll see an example of a range query, as well an example of how the indexes can be leveraged automatically by the query optimizer.

Consider the following XML:

Let's create a path range index on /widget/part/@count. This time, since the document uses a namespace, we need to define a "path namespace" first:

Click the "Add" button and then enter a prefix of your choice ("w" in this example), along with the namespace used by the above document:

Click "OK" and then click "Path Range Indexes" (the next item in the menu above). Click "Add" and enter the details of the path, using the prefix we just bound:

This time we've chosen integer ("int") for the data type. Note that we use the "w" prefix on the element steps (but not the @count attribute since the default namespace doesn't apply to attributes).

Once this is configured, we can access all the values (as with the example in part 1), using cts:values:

Note that the path index is identified by the path itself. I used a different prefix in this example just to drive home the point that the path doesn't have to be exactly the same string you configured; it truly doesn't matter what prefix you use when you initially configure the index. If your database contains just the one XML document above, then the above query will return the number 30. Note that we didn't specify the type of the index this time in our call to cts:path-reference. That's only necessary if you have more than one index with the same path (but different types or collations).

Now let's look at a path range query using the index we configured and the cts:path-range-query constructor:

The above query will find all documents where the count is greater than 20.

Finally, we can use regular XPath and it will still make use of the range index via automatic optimization:

To prove this, enable query tracing with xdmp:query-trace:

If you look in the error log, you'll see that the results were narrowed down to 1 document using the indexes alone:

The basic rule is that a path index gets used for optimizing queries if there's a predicate in the query that matches the path range index. If you're unsure whether a given XPath will be optimized (every release of MarkLogic adds new optimizations), use xdmp:query-trace as in the above example and look at the error log to see whether or not the index was leveraged.

That's all for now! If you have any questions, please submit a comment and I'll be sure to reply!