[ 
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560259#action_12560259
 ] 

Christoph Kiehl commented on JCR-1196:
--------------------------------------

Description for slow ChildAxisQuery by Martin Zdila (JCR-1324):

I have following structure in my repository:

jcr:root
        gfr:devices
                gfr:device
                        gfr:capabilityMap

There are cca 4000 gfr:device nodes. Each gfr:device has only one 
gfr:capabilityMap. Each gfr:capabilityMap has average 20 properties.

Here are some interesting results:

1.
((QueryImpl) query).setLimit(30);
((QueryImpl) query).setOffset(anyLimit);

1.1
executing query //gfr:capabilityMap and fetching nodes takes cca 20-80ms

1.2
executing query /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap and fetching 
nodes takes cca 2000ms

Why does this take longer time if the only difference is more specific path? I 
would expect even shorter time of execution and not this.

2.
now without proprietary limit/offset

2.1
//gfr:capabilityMap
cca 150-200ms

2.2
/jcr:root/gfr:devices/gfr:device/gfr:capabilityMap
cca 14000ms!!!

> 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.

Reply via email to