Le 3/14/12 3:51 PM, Carlo.Accorsi@ibs-ag.com a écrit :
> 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)
> )
>
> OR
>
> (&
> (&(objectclass=top)
> (objectclass=person)
> (objectclass= organizationalPerson)
> (objectclass=inetOrgPerson))
> (uid=jsmith)
> )
>
>
>
It depends on the number of entries selected by each of the filters. The
way the filtering works - for an AND operation at least - is that we
first evaluate the number of elements returned by each single filter,
then we pick the smallest one and we process the search using this filter.
For instance, in your case, we will have :
(objectclass=top) -> matches all the entries (obviously)
(objectclass=person) -> matches 1000 entries
(objectclass= organizationalPerson) -> matches 100 entries (less than for the previous
filter because organizationalPerson has person as a superior)
(objectclass=inetOrgPerson) -> matches 10 entries (same raisonning than upper)
now,
- if (uid=jsmith) matches 55 entries, then we will use the (objectclass=inetOrgPerson) filter
- if (uid=jsmith) matches 7 entries, then we will use this filter
at the end, we will browse 10 or 7 entries, depending on the number of matched entries considering
the filter.
If we take your first filter
(&
(objectclass=inetOrgPerson)
(uid=jsmith)
)
it's even simpler, as we don't have to evaluate the hierarchy of ObjectClasses.
End of the day : no need to pile up the atomic filters in your request, just use those that
are the most discriminant.
Last, not least, the 'cost' difference will be minimal anyway, as the evaluation is a pretty
fast operation compared to pulling entries from the backend to return them. You will see no
difference.
The best thing to do is to have the correct index set depending on the requests you will submit.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com