[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560972#action_12560972
]
Ard Schrijvers commented on JCR-1196:
-------------------------------------
With the fixed caching I cannot imagine that
>2.2
>/jcr:root/gfr:devices/gfr:device/gfr:capabilityMap
>cca 14000ms!!!
takes 14000 ms *after* the first execution. Can you attach your test case? You
are sure you are measuring the time *after* the first time you execute the
query? Can you tell me how large the resultset is (getSize()) when not using a
limit/offset. If the resultset is in the order of 10^6 you might have
performance issues when using paths in your query, even with the fixed cache.
This is a known issue.
> Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
> ------------------------------------------------------------
>
> Key: JCR-1196
> URL: https://issues.apache.org/jira/browse/JCR-1196
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core, query
> Reporter: Ard Schrijvers
>
> A query like
> /documents/en/news//[EMAIL PROTECTED] order by @modificationDate
> when there are many nodes ( > 1.000) in /documents/en/news becomes very
> slow. I think the bottleneck is in something like recursive filters in
> lucene. First off all I'll try to find some stastistics about the
> performance, and describe the bottleneck. After that, a solution must be
> found, where we need to keep in mind that
> 1) these queries run faster and scale better (obviously)
> 2) moving a node must stay a cheap operation
> Also see:
> http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
