tim stone wrote:
The index is working as designed, it's just filled with a lot of false matches which have to be explicitly tested against the filter to be weeded out. The objectclass index provided 355545 candidates in the range of 228 thru 355772. Some other search term provided (355755-112277) candidates, leaving the range from 112277 thru 355755 needing to be tested. If this search takes too long, then you need a larger entry cache.
Hello Howard,
but why is the index filled with a lot of false matches?
In one of my DN (Container) are 88000 entires. I placed my search there (searchBase). Only the Container itself has the searched objectClass, but all entires in this container will be examined too, because the index returned this all. Should the index for objectClass not only give back this _one_ (and not 355545) Candidate, because I placed my search there? Do I misunderstood this?
An index is only a hint, it is not definitive. It is generated from a short hash of the relevant attribute values. It's always possible to have hash collisions, where multiple values hash to the same index.