Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 7 Feb 2013 12:31:14 +0000 (UTC)
From: "Tom Quellenberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12631243.1360240187713.259797.1360240274109@arcas>
In-Reply-To: <JIRA.12631243.1360240187713@arcas>
References: <JIRA.12631243.1360240187713@arcas>
Subject: [jira] [Created] (JCR-3513) Slower range query execution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Tom Quellenberg created JCR-3513:
------------------------------------

             Summary: Slower range query execution
                 Key: JCR-3513
                 URL: https://issues.apache.org/jira/browse/JCR-3513
             Project: Jackrabbit Content Repository
          Issue Type: Improvement
    Affects Versions: 2.4.3
            Reporter: Tom Quellenberg


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