Steeg Carson wrote:
2011/1/4 Quanah Gibson-Mountquanah@zimbra.com:
--On Tuesday, January 04, 2011 1:43 AM +0100 Steeg Carson steeg.carson@googlemail.com wrote:
I simulate this on my database just right now:
I suggest you read:
http://www.openldap.org/lists/openldap-technical/201011/msg00146.html
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 LDAP_PVT_THREAD_STACK_SIZE.
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.