directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Updated: (DIRSERVER-933) Slow searches using a non-indexed attribute in a filter
Date Wed, 16 May 2007 17:09:16 GMT


Alex Karasulu updated DIRSERVER-933:

             Priority: Critical  (was: Major)
    Affects Version/s:     (was: 1.5.1)
        Fix Version/s: 1.5.1

This is incredibly insightful Martin and a very good catch.  I will raise the priority of
this issue and make sure we get a fix for it in 1.5.1.  If you are interested in working with
us to improve the performance of the JDBM partition feel free to supply a patch.  We would
love to have more sharp contributors like yourself become committers.  Thanks again for catching
this bug and describing it so well in this JIRA.

NOTE: Fixing this issue will result in properly leveraging the system indices, namely the
normalized name index to take DN and scope into account.  This will dramatically improve search
performance when no attribute in the search filter is indexed.

> Slow searches using a non-indexed attribute in a filter
> -------------------------------------------------------
>                 Key: DIRSERVER-933
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.5.0
>            Reporter: Martin Alderson
>            Priority: Critical
>             Fix For: 1.5.1
> When searching for entries in a specific container with a filter such as (cn=*) and the
cn attribute is not indexed, the server has to test each entry in the partition even when
the search has been restricted to a container.
> As an example of how bad this could be - if a partition contains millions of entries
and the user does a search in that partition within a container that only contains 1 of those
entries, every entry in the partition is checked in turn even though the server knows there
is only one entry within the specified container.
> This is due to the search optimizer which annotates each part of the filter with the
number of entries that match where it can.  For those it can't (such as with attributes that
are not indexed) this 'count' will default to Long.MAX_VALUE - to indicate that it is the
worst case.  (See
> When these count annotations are checked to decide which part of the filter to use first
they are dropped down to integers which means the items with the worst case value of Long.MAX_VALUE
become -1 -- effectively making them the best case.  (See
> Disclaimer: I have not done any performance testing on this.  I just noticed the problem
while stepping through the code with a debugger.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message