[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Index for objectclass does not work...

Steeg Carson wrote:
2011/1/4 Quanah Gibson-Mount<quanah@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:


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.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/