On Dec 16, 2010, at 11:01 AM, Tim Meagher wrote: > Hi Jason, > > I guess what I don't understand is how the range query within a cts:search > uses a range index. I'm used to associating range indexes with lexicon > searches. In the case of lexicon searches, the frequency of occurrences > depends on the number of fragments in which an indexed value occurs, so I > don't understand how the range searches work with cts:search in contrast to a > term search such as cts:element-value-query. I'm probably just not > understanding the big picture correctly.
The range index can be thought of as an in-memory data structure that maps fragment ids to values (sorted by fragment id), and values to fragment ids (sorted by values). So when doing a lexicon call you use the id->value mapping to quickly get values for ids resolved by other indexes. But when using a range query constraint, you use the value->id mapping to quickly get the fragment ids matching the query value constraint. > > I would expect the range query to be faster than cts:element-value-query for > exact queries as it takes advantage of range indexes rather than a term list. Both will be extremely fast. Fast enough that I wouldn't worry about which one is technically faster. > However, the range query doesn't provide all the nice search options (case, > punctuation sensitivity choices…). Why would one ever use > cts:element-value-query() with the exact option if range queries are faster? Ah, because you might not have the range index enabled. > Why not include the various sensitivity options with the range query? You do get collation options with a range index, which gives you various sensitivity options. -jh-
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
