I would rephrase this as "does the evaluator ever use indexes for where clauses?" If indexes are used at all, I would expect ranges to work too. And with 6.0-1.1 the answer seems to be "yes" - but I would still recommend doing as much as possible in XPath predicates.
Here's a contrived test. In real life it would be very odd to have a dls:created element in the main document, but since the range index comes preconfigured it's handy for testing. declare namespace dls="http://marklogic.com/xdmp/dls";; xdmp:document-insert( 'test/1', element a { element b { 'c' }, element dls:created { xs:dateTime(xs:date('2012-12-01')) } }), xdmp:document-insert( 'test/2', element a { element b { 'c' }, element dls:created { xs:dateTime(xs:date('2012-12-12')) } }) => () Now we have two documents that match the /a[b eq 'c'] portion of the expression, but with different dsl:created values. Let's write a test query that matches one, but not the other: declare namespace dls="http://marklogic.com/xdmp/dls";; xdmp:query-trace(true()), for $n in /a[ b eq 'c' ] where $n/dls:created < xs:dateTime(xs:date('2012-12-12')) return $n One document should match the dls:created constraint, and the other shouldn't. The actual results match expectations, but that could be due to filtering. Let's check the trace: 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Analyzing path for $n: fn:collection()/a[b eq "c"] 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Step 1 is searchable: fn:collection() 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Step 2 is searchable: a[b eq "c"] 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Path is fully searchable. 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Gathering constraints. 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:14: Comparison contributed hash value constraint: b = "c" 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Step 2 predicate 1 contributed 1 constraint: b eq "c" 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:14: Comparison contributed hash value constraint: b = "c" 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Step 2 predicate 1 contributed 1 constraint: b eq "c" 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Step 2 contributed 2 constraints: a[b eq "c"] 2012-10-22 09:06:18.661 Info: 8003-cq: at 5:9: Comparison contributed dateTime range value constraint: dls:created < xs:dateTime("2012-12-12T00:00:00") 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Where clause contributed 1 constraint for $n: $n/dls:created < xs:dateTime("2012-12-12T00:00:00") 2012-10-22 09:06:18.661 Info: 8003-cq: at 4:11: Executing search. 2012-10-22 09:06:18.667 Info: 8003-cq: at 4:11: Selected 1 fragment to filter That looks exactly as expected (aside from the duplication of b=c, anyway). If we increment the date to the 13th or the 31st, both fragments match. If we try to use a QName that doesn't have a range index, we lose the "Comparison contributed dateTime range value constraint" line. So it seems clear that the range index is used for the where-clause. Note that the same expression will be unsearchable according to xdmp:plan, though. Presumably that's because the FLWOR expression taken as a whole is unsearchable. That's understandable, but a little frustrating. Even knowing this, I would still recommend doing as much as possible in XPath predicates. For one thing, you can use xdmp:plan instead of xdmp:query-trace. -- Mike On 22 Oct 2012, at 08:02 , David Sargeant <[email protected]> wrote: > I'm wondering if ML uses a range index in the where portion of a FLOWR > expression where applicable. I could only find examples of 'order by'. > Thanks. > > > > David > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
