On Wed, Mar 14, 2012 at 6:17 PM, Emmanuel Lécharny <[email protected]>wrote:
> 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 ? > > 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
