No it's not. doc is, but not body.
Jason Hunter wrote:
Hi Mike,
You don't mention it, but <body> is a fragment root, right?
-jh-
Mike Sokolov wrote:
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
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
