My testing has usually show that not() is measurably slower than what I call a 
"materialized not" - something like your "<child values-exists='no' />" 
example. It would be even faster to use a distinct element QName such as 
"<empty-child />".

In the real world, though, these differences are sometimes slight and may not 
be significant. CPUs are fast.

-- Mike

On 31 May 2011, at 14:24 , [email protected] wrote:

> I'm hoping someone can validate my understanding. From what I can tell 
> through performance measuring, using fn:not() does not automatically my a 
> query unsearchable (ie, not go against the index).
> 
> Given XML files in the DB that look like this :
> 
> <stuff>
>      <child>Alan</child>
> </stuff>
> 
> where there will always be a child element but there may or may not be a 
> value.
> 
> If I write an XPath expression like this:
> 
> /stuff[fn:not(child/text())]
> 
> Then according to xdmp:plan(), the XPath is fully searchable, and according 
> to the profiler, runs without a performance penalty because of the fn:not().
> 
> So my questions are: Are the absences of element values as fast as (or nearly 
> so) as existing values in terms of using the indexes in queries? In other 
> words, is querying for the absence of a value as fast as querying for a value?
> 
> Is there a faster way to query for an absent or empty value? I could change 
> the data so that there would be no "child" element if there is no value for 
> the element. Would that matter in terms of performance? Would it be faster to 
> have "<child values-exists='no'></child>" and use that attribute in a 
> positive query rather than just <child/> with a negative query?
> 
> From my testing, it seems like using fn:not() in this case is just as good as 
> anything else. But I suspect there's more to the story.
> 
> Thanks,
> Ryan
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general

_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to