I stumbled on a surprising behavior and wanted to know if anybody has a
good heuristic for identifying this odd little performance bottleneck in
MarkLogic so as to avoid it (there is an easy alternative expression
that works better).
If I run the query:
cts:search(//doc, cts:element-attribute-value-query (xs:QName('doc'),
xs:QName('e:id'), '/opr/t125/e1646'))/body,
I get results quickly (.002 sec)
However the very similar query
//[EMAIL PROTECTED]'/opr/t125/e1646']/body
takes 1.37 sec, almost 1000x slower!
query-meters reveals that it involves 85,000 tree-cache-hits and touches
various documents, when in fact there is only a single fragment in the
system matching the given attribute value. Similarly query-trace says
"Selected 7212 fragments to filter," although I'm not sure why.
Somehow adding the /body element seems to be the culprit since:
//[EMAIL PROTECTED]'/opr/t125/e1646']
is quite fast, as is
let $doc := //[EMAIL PROTECTED]'/opr/t125/e1646']
return $doc/body
Does this seem surprising to anyone else? I have been trying to use
xpath whenever I can due to its elegant simplicity in comparison with
the cts: functional operators, and I thought I had a good internal sense
of when an expression could get run quickly using indexes, but now I am
beginning to worry about other possible performance bottlenecks I may
have overlooked.
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
