jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <msl...@email.cz>
Subject Re: Re: XPath path constraint
Date Fri, 08 Feb 2013 07:52:37 GMT
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 <aklimets@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message