[ 
https://issues.apache.org/jira/browse/JCR-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Parvulescu updated JCR-3513:
---------------------------------

          Component/s: jackrabbit-core
    Affects Version/s: 2.6
                       2.5
                       2.5.1
                       2.5.2
                       2.5.3
    
> Slower range query execution
> ----------------------------
>
>                 Key: JCR-3513
>                 URL: https://issues.apache.org/jira/browse/JCR-3513
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>    Affects Versions: 2.4.3, 2.5, 2.5.1, 2.5.2, 2.5.3, 2.6
>            Reporter: Tom Quellenberg
>            Assignee: Alex Parvulescu
>             Fix For: 2.6.1, 2.7
>
>         Attachments: JCR-3513.patch
>
>
> After switching from JachRabbit 1.6.4 to 2.4.3 we experienced extreme slow 
> query executions. All range query on date fields are often 10 times slow than 
> before.
> In our repositories more than 1 million documents are stored which all 
> contain for example a creation date. Typical queries look like this:
> //element(*, sophora-nt:story)[@sophora:creationDate > ...]
> JackRabbit has its own RangeQuery implementation which is used when Lucene 
> throws a TooManyBooleanClauses-exception (and in some other situations, too). 
> This worked well in Jackrabbit 1.6. In newer versions a different Lucene 
> library is used which never throws TooManyBooleanClauses exceptions. Instead, 
> is has its own fall-back in situations where a BooleanQuery does not work. 
> This fall-back with a MultiTermQueryWrapperFilter seams to us much slower 
> than the fall-back implementation in JackRabbit (Does anybody know the 
> reason?). It is the same situation in Jackrabbit 2.6.0 (with Lucene 3.6.0)
> We patched org.apache.jackrabbit.core.query.lucene.RangeQuery to never use 
> org.apache.lucene.search.TermRangeQuery but always use the JackRabbit 
> implementation. This leads to query executions as fast as in older Jackrabbit 
> versions.
> Do other people experience this problem? Are there any drawbacks using always 
> the JackRabbit implementation for range queries? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to