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 <jjverder...@gmail.com>
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, <msl...@email.cz> 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"
