jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: SQL query processing bug?
Date Wed, 13 Feb 2008 08:11:25 GMT
Alex Lukin wrote:
> Hi, all!
> Being disparate with XPath query performance I tried SQL query and results
> was  even worse.

the only difference between XPath and SQL is syntax, the underlying execution is 
the same. If you see differences in performance then the two queries are not 
equivalent.

> Queries:
>  
> 1: "SELECT * FROM nt:base WHERE jcr:path LIKE '/foo/bar[%]/%'"
> 2: "SELECT * FROM nt:base WHERE jcr:path LIKE '/foo/bar[%]/%'/%"
> 2: "SELECT * FROM nt:base WHERE jcr:path LIKE '/foo/bar[%]/%'/%/%"
> 
> Query 1,2, and 3 give the same results - nodes at /foo/bar.

what version of jackrabbit are you using? With the current trunk, which already 
includes changes from JCR-1365, results are different. if you have a node 
structure /testroot/a/b/c/d the results are:

select * from nt:base where jcr:path like '/testroot/%'
   /testroot/a
   /testroot/a/b/c/d
   /testroot/a/b/c
   /testroot/a/b
select * from nt:base where jcr:path like '/testroot/%/%'
   /testroot/a/b/c/d
   /testroot/a/b/c
   /testroot/a/b
select * from nt:base where jcr:path like '/testroot/%/%/%'
   /testroot/a/b/c/d
   /testroot/a/b/c
select * from nt:base where jcr:path like '/testroot/%/%/%/%'
   /testroot/a/b/c/d

> Only difference is: query 2 runs longer that 1, 3 longer that 2. BTW, too
> long (12 sec q. 3) for my 10 nodes in "bar" level with 40 nodes under
> "bar/%/".

This has been improved with the latest changes for JCR-1365.

regards
  marcel

Mime
View raw message