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
