Christoph Kiehl wrote:
Christoph Kiehl wrote:
I was digging a bit into Jackrabbit today and found another place
where some caching did provide a substantial performance gain to
queries which check one attribute for more than one value (like
/foo/[EMAIL PROTECTED]:bar='john' or foo:bar='doe']). The BitSet in
calculateDocFilter() is right now created twice for the query above.
On large repositories this takes about 200ms per BitSet on my machine
for a particular field. Caching these BitSets per IndexReader and
field in a WeakHashMap with the IndexReader as a key gave me some real
improvements.
agreed, this should definitively be cached per index segment and is doable with
reasonable effort.
I've created a jira issue: http://issues.apache.org/jira/browse/JCR-791
Replying to myself ;):
- I was referring to calculateDocFilter() in
org.apache.jackrabbit.core.query.lucene.MatchAllScorer
- The achieved performance improvement varied between 30-60% depending
on the actual query
but that means your query is rather:
/foo/[EMAIL PROTECTED]:bar]
right?
@foo:bar='john' should be translated into a term query.
regards
marcel