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
