[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: objectClass index from slapd.conf is not working
- To: Howard Chu <hyc@symas.com>
- Subject: Re: objectClass index from slapd.conf is not working
- From: tim stone <timstone10001@googlemail.com>
- Date: Tue, 14 Sep 2010 11:09:19 +0200
- Cc: openldap-technical@openldap.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BF/Y9YAllLH7B23jJpJosdj3M2UZxUWJ1MeaGHPqGEo=; b=gIWDakfqGXxE6/8trkmXA+sWBp0o54vcrblzq3wRCnF497wREQ1WMz1KHI/MKx3Tym h7kd0WaT2VtYU+g3HaYOUAUEC622efdY3pQL5LFJ6DhLU8Z+oNe2Za9+DGNtY1jqVwX0 idvdPvRy6kLSSIcSoI7e7AELj+jso1LmbpBAU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WmA3hJTj7vEYi+C3FHhsxcTKREVj5jKfLH3I5j1fOW/Bs7FkQy/3vv8PbT6n2o8BAs mWEAn8KlHogjhCTVBEwHEyvxTr7aoLf4O2kdNppNE3alo/NztBaY3//s6uaLgYIFnN3g 6OEkyg9x2C/x7FwY4yNu/5/9vhBA8b8hV2J78=
- In-reply-to: <4C88D1B1.2040101@symas.com>
- References: <AANLkTi=7ERgBcREr7mWJ+-DkYpCAr+kW=FzWaqcxms3+@mail.gmail.com> <4C88D1B1.2040101@symas.com>
>
> 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?
Thanks Tim