[Date Prev][Date Next]
Re: Index for objectclass does not work...
Steeg Carson wrote:
2011/1/4 Quanah Gibson-Mount<firstname.lastname@example.org>:
--On Tuesday, January 04, 2011 1:43 AM +0100 Steeg Carson
I simulate this on my database just right now:
I suggest you read:
to understand how indices and their slots work.
As I now understand, the entire index for one attribute (e.g.
objectClass) is "split" in several indexes. They holds for each
path/node (resp. DN, but not leaf) an separate index for this
attribute with all "hits" for his subtree (and for onelevel too).
No. Only the dn2id table maintains any notion of nodes and subtrees. All
indices are global to the database and have no notion of scope.
If I do an ldapsearch with -b "cn=ownPath,ou=root" the slapd takes the
index which is bound on this node/DN?
In my DIT are 470812 entires.
The objectClass=subEngine exists 104384 times in the entire directory (ou=root).
The objectClass=subEngine exists only 1 time under "cn=ownPath,ou=root",
By default an index slot can only maintain 65535 records before it overflows
and loses precision. Once it loses precision, you tend to get results like
this. If you need to accomodate larger indices you can tweak a constant in
back-bdb/back-bdb.h and recompile. You'll probably also need to increase
Another workaround, without recompiling, would be to sort your entries such
that all of the entries of the subEngine class are loaded in contiguous order.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/