Hopefully other people chime in here, I've only had bad experiences with utilizing queries and have often resulted in personally never using them - so I always end up iterating/navigating myself.
Theoretically if you have a REALLY GOOD index then you may get some similar performances, but if your index(es) are inefficient, then it's just wasted CPU cycles (you'd wish those CPU cycles were going to a good cause, but they're not). the transition of Sling (and AEM) to Oak from Jackrabbit 2.x made this experience worse with the awkward indexing policies/process in Oak, and the fact that Oak never seemed to ever use multiple indexes. Oak always seemed to calculates the costs of the entire query against all the available indexes and only chooses the ONE best index. This sounds like a good idea in theory, but then most DBMS I've used in the past utilize ALL the indexes they can - not just one. So basically i guess this comes to be "If you have a good index (in that it can apply to ALL the conditions/attributes/properties of your query) then using a query should be fine, otherwise iterate yourself" having any condition missing from the index can be fatal in performance, such as lacking the evaluatePathRestrictions = true, which without it is basically death of the system if you have a lot of content. But really, I hope some other people with more positive experiences can provide some better advice. On Thu, Jun 16, 2016 at 11:08 PM, Roy Teeuwen <r...@teeuwen.be> wrote: > Ok, it would be handy to have an estimate on the approximate amount / levels > of resources when to go for iterating vs querying :). > > Greets > Roy >> On 16 Jun 2016, at 16:06, Steven Walters <kemu...@gmail.com> wrote: >> >> if you know there are that few resources, then I say iterating would be >> better performing than XPath / JCR-SQL2 queries. >> This is primarily from past experience speaking in that queries have >> generally turned out (often MUCH) slower than directly iterating if you >> know what you're actually looking for. >> >> >> On Thu, Jun 16, 2016 at 10:28 PM, Roy Teeuwen <r...@teeuwen.be> wrote: >> >>> Hello all, >>> >>> Lets say I got a resource with around 10-20 child/grand-child resources, >>> not going deeper than 3 levels max. What is the most performant when >>> searching for the child resources containing a specific property (the >>> property is configurable with OSGi, so hard to put an index on it). >>> Iterating the child / grand-child resources until you find it or making an >>> xpath/jcr-sql2 query? When would one option start to be more performant >>> than the other. >>> >>> Thanks! >>> Roy >
