directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Is it faster/better to include one objectclass or all in query?
Date Thu, 15 Mar 2012 09:33:36 GMT
On Wed, Mar 14, 2012 at 6:17 PM, Emmanuel Lécharny <>wrote:

> Le 3/14/12 5:08 PM, Alex Karasulu a écrit :
>  On Wed, Mar 14, 2012 at 4:51 PM,<>  wrote:
>>  Hi, when searching for a user having this objectclass hierarchy
>>> top
>>>  |_person
>>>         |_organizationalPerson
>>>                    |_inetOrgPerson
>>> and uid = 'jsmith'
>>> Which query would be less expensive or better/faster?  Thanks!
>>> (&
>>>   (objectclass=inetOrgPerson)
>>>   (uid=jsmith)
>>> )
>>>  This would be faster and more efficient since the evaluation is on a
>> more
>> specific objectClass which reduces the search space from the get go.
>> To understand this you need to know about how the optimizer works with
>> scan
>> counts that are returned. LDAP search filters are expanded out into an AST
>> (abstract syntax tree) with the leaves of the tree being assertions the
>> branch nodes being operators. Then the optimizer annotates this AST with
>> scan counts, which basically is asking each index, "Hey how many results
>> would you return for this assertion?" So the more specific inetOrgPerson
>> is
>> more likely to return a smaller scan count.
>> Now if you have an index on uid then the scan count on this will be 1
>> since
>> UID should be unique (our DSA does not enforce this tho)
> Uh ?
The DSA does NOT enforce UID uniqueness so this is may be a problem if your
application or organization does not enforce this was my point.

> Sorry, Alex, but if you manage more than one linux server, you might have
> more than one uid in your LDAP server, no ? Plus uid is not a SINGLE_VALUE,
> so you maye have more than one value in the AT.
I was trying to say the same thing. You might have more than one jsmith uid
because this is not enforced by the DSA.

> You may have a higher number of uid=XXX in this case.
>  If you do not have an index on uid I suggest you index it. But if you
>> don't
>> then the candidates will be generated off the objectClass index which
>> always exists since it is a system index. The server will then iterate
>> through the entire set of inetOrgPersons in your DIB and de-serialize the
>> entry from the master table then check (after normalizing the uid
>> attribute) if it is in fact equal to jsmith. This could be huge.
> Yeah, this is a better explaination than mine : ObjectClasses are indexed
> DIT wide.
>> So index your uids and don't bother with the objectClass stuff if you
>> don't
>> vary the OC of the people in your DIB.
> This is the right thing to do, really.

Best Regards,
-- Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message