directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
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 <elecharny@gmail.com>wrote:

> 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 ?
>
>
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

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