The index is the same for both xpath and sql-2, and that index doesn't index paths (to support simpler/faster moves), so the issue that the path constraint slows things down is conceptual.
If you see that it makes a big difference (w/ path constraint) between xpath and sql-2, it would be interesting to see the numbers and find out where xpath is wasting additional time. Cheers, Alex On 30.01.2013, at 04:24, [email protected] wrote: > Yes it is possible. SQL2 with path constraint works ok. I made some > measurement for our use case > (we perform many queries 10^4 on big data 10^4 and result set is quite small > typically <10). I compared > XPath and SQL2 with and without path constraint. When I did not use path > constraint in query I did my own > filtering on node path from result set. > > For SQL2 with/without path constraint time is comparable - query with path > constraint is slower but I did not compute > any statistics and time has error comparable with time difference. > > XPath without path constraint is still considerably faster (even with > programmatic filtering on result set - it filters small number of > nodes) difference is: XPath is 3 times faster than SQL2 on our use case. > > So for us it is still better to use XPath without path constraint and > perform path filtering on query result. > > Our query is as follows: > XPath: > statement.append("//*["); > statement.append("@").append(propertyName).append("='"). > append(uuid).append("'"); > statement.append("]"); > SQL2: > statement.append("SELECT * FROM [nt:base]"); > statement.append(" WHERE ").append(propertyName).append("='" > ); > statement.append(uuid).append("'"); > // Optional path constraint > statement.append(" and ISDESCENDANTNODE([/documents])"); > > propertyName is name of node property and uuid is property value. > Property is multivalue property with REFERENCE type. > > Marek > > > ---------- Původní zpráva ---------- > Od: joe verderber <[email protected]> > Datum: 30. 1. 2013 > Předmět: Re: XPath path constraint > > "Marek, > > Have you considered using a JCR-SQl2 query? It may give better performance. > > --Joe > > On Tue, Jan 29, 2013 at 8:14 AM, <[email protected]> wrote: > >> Hi, >> >> I want to ask if there is any plan to optimize or fix performance of XPath >> query with path constraint. I asked about my problem a while >> ago. It was as follows: >> >> If I have node structure /a/b and want to find out all nodes b with >> property >> p which has value 'v1' I can use >> either XPath expression with path constraint >> //a/b[@p='v1'] >> but this is quite slow (both query and then iteration over result set). >> So we use query without path constraint: >> //*[@p='v1'] >> It is considerably faster (more than 10times) but it is error prone. Even >> if >> we try to keep property names globally unique >> we still use some subtree to store 'invalid' nodes which will need some >> manual intervention but we do not want those nodes >> to be returned. So we either have to filter result (using path prefix) or >> go >> back to path constraint in query but then we are back to >> very poor query performance. >> >> So my question is: Is there any plan to handle bad query performance when >> path constraint is used in XPath query? >> >> Thanks >> >> Marek >> > > > > -- > > > --Joe Verderber"
