> George Daswani wrote: >> Hello, >> >> I have around 350K users in my test directory, and I'm running >> into an odd problem with the directory not using indeces for >> ldapsearches. >> >> For example, using the following search string >> >> (&(objectClass=icasOrgPerson)(employeeNumber=*)) >> >> Looking at the console, there's a system index on objectClass (which is >> set to equality), there's also an index on employeeNumber (both >> equality, >> and presence). >> >> There are around 5K icasOrgPersons (which can hold the employeeNumber >> attribute), the rest can't. > How many entries match (objectClass=organizationalPerson)? If this > number is large, then I think what's happening is that the database > first looks up how many match this, and says there are too many. Try > using icasOrgPerson or reverse the order of the filters. I did the following per your statement above.. ldapsearch -D "cn=Directory Manager" -x -W "(&(employeeNumber=*)(objectClass=icasOrgPerson))" -b "ou=Users,ou=Internal,o=TEST,o=US" ou=Users,ou=Internal,o=TEST,o=US only holds icasOrgPerson type users (4778 in total) and all of those records have an employeeNumber. the rest of the users live in ou=Users,ou=External,o=TEST,o=US (around 345K+, none of which are icasOrgPerson's) Running the search string above, the search is still unindexed (returns nentries=4778 notes=U) and is slow. Searches like the following are very fast (indexed per the access log) "(&(employeeNumber=2549)(objectClass=icasOrgPerson))" it's weird that searches are so slow (not using indeces) considering the number of actual icasOrgPerson (objectClass) is quite low (5K out out of the 450K users), and that there's a presence index on the employeeNumber attribute (which only exists in icasOrgPerson objects) along with a searchbase. The index files aren't corrupt and I even recreated the database using ldif2db just to make sure everything was fine with the same result.
