jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: XPath path constraint
Date Thu, 07 Feb 2013 22:39:03 GMT
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 <jjverderber@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, <mslama@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"

Mime
View raw message