[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561005#action_12561005
]
Ard Schrijvers commented on JCR-1196:
-------------------------------------
t3 is 453 sec for ni.hasNext()!!
This is indeed a different issue AFAICS. ATM, I am occupied with some other
work, but I'll try to investigate the issue thie evening or tomorrow evening.
I'll get back on this one, try to reproduce your numbers, and thanks so far for
investigating the issue.
By the way: did you implement a custom accessmanager?
> 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
> Attachments: jcr-repository-xml-dump.xml.bz2
>
>
> 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.
