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

Reply via email to