Le 3/14/12 5:08 PM, Alex Karasulu a écrit :
On Wed, Mar 14, 2012 at 4:51 PM,<[email protected]> 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.
