Hi, sbarriba wrote: > I've included some background below but my question is..... "is using > jcr:path in a query to be avoided due to performance"?
I'd say, it depends on the query and the content structure you have. but in general, path constraints are more expensive than constraints on properties. btw, what version of jackrabbit are you using? evaluation of path constraints have been improved in jackrabbit 1.5 for certain queries. > As the number of stories has increased we're seeing more and more incidents > of queries exceeding 2 secs. Furthermore we've seen lucene start to use more > and more heap space executing these queries. Based on > http://www.nabble.com/Explanation-and-solutions-of-some-Jackrabbit-queries-r > egarding-performance-td15028655.html I understand that the above query would > be much faster if we added a tag/category type property to the object e.g. > acme:category = "Sport" so that the query could be > > SELECT * FROM acme:Story WHERE acme:category LIKE 'Sport' ORDER BY > acme:createdDate DESC > > Is that a fair assessment? this will probably be faster than a query with a path constraint, though the memory consumption will stay high. lucene loads all values of the property to sort by into memory. depending on the size of the value this results in quite significant memory usage. regards marcel
