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

subinitial and subfinal indexes not working (ITS#2588)



Full_Name: Andreas Hasenack
Version: 2.1.21
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (200.181.170.6)


slapd.conf, index I'm using:
index   cn,sn,mail      eq,subinitial,subany,subfinal

I also tried with just "eq,sub", same results.

searches being performed: string, *string*, *string and string*.
"string" and "*string*" are very fast (<1s), while "*string" and "string*" are
very slow (>10s).
Results below, excerpts from the slapd log for the searches above:

Jun 10 11:39:04 matrix slapd[31093]: conn=0 op=1 SRCH base="o=myCompany" scope=2
filter="(mail=Employee-2@section-90.mycompany.com)"
Jun 10 11:39:04 matrix slapd[31093]: conn=0 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=

Jun 10 11:39:25 matrix slapd[31093]: conn=1 op=1 SRCH base="o=myCompany" scope=2
filter="(mail=*Employee-2@section-90.mycompany.com*)"
Jun 10 11:39:25 matrix slapd[31093]: conn=1 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=

Jun 10 11:41:23 matrix slapd[31093]: conn=3 op=1 SRCH base="o=myCompany" scope=2
filter="(mail=*Employee-2@section-90.mycompany.com)"
Jun 10 11:41:41 matrix slapd[31093]: conn=3 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=

Jun 10 11:42:18 matrix slapd[31099]: conn=4 op=1 SRCH base="o=myCompany" scope=2
filter="(mail=Employee-2@section-90.mycompany.com*)"
Jun 10 11:42:43 matrix slapd[31099]: conn=4 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=

For this test I created a dummy database with about 108k entries in the
following format:
dn: o=myCompany
o: myCompany
objectClass: top
objectClass: organization

dn: ou=Departments, o=myCompany
ou: Departments
objectClass: top
objectClass: organizationalUnit

dn: ou=Section-1, ou=Departments, o=myCompany
ou: Section-1
objectClass: top
objectClass: organizationalUnit

dn: ou=People, ou=Section-1, ou=Departments, o=myCompany
ou: People
objectClass: top
objectClass: organizationalUnit

dn: uid=Employee-1, ou=People, ou=Section-1, ou=Departments, o=myCompany
uid: Employee-1
cn: Employee-1-cn
givenName: Employee-1-gn
sn: Employee-1-sn
mail: Employee-1@Section-1.mycompany.com
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/Employee-1
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
objectClass: posixAccount

Then there is Employee-2, 3, etc for Section-1, then all over again for
Section-2 and so on. The only globally unique attribute is the mail one.
As a sidenote, this also happens with at least openldap version 2.0.25 and
2.0.27 (I didn't test other versions).