directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Is it faster/better to include one objectclass or all in query?
Date Wed, 14 Mar 2012 16:17:31 GMT
Le 3/14/12 5:08 PM, Alex Karasulu a écrit :
> On Wed, Mar 14, 2012 at 4:51 PM,<Carlo.Accorsi@ibs-ag.com>  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 ?

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.

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.

Mime
View raw message