You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2013/02/07 23:39:03 UTC
Re: XPath path constraint
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, mslama@email.cz 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 <jj...@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, <ms...@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"
Re: Re: XPath path constraint
Posted by ms...@email.cz.
There is huge difference between XPath and SQL2 query with path constraint.
(Both query execution and result set iteration.)
I will try to make simple app and make some profiling. Without path
constraint SQL2 is slower than XPath.
Marek
--
Marek Slama
mslama@email.cz
---------- Původní zpráva ----------
Od: Alexander Klimetschek <ak...@adobe.com>
Datum: 7. 2. 2013
Předmět: Re: XPath path constraint
"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, mslama@email.cz 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 <jj...@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, <ms...@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""