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).
changed notes
changed notes moved from Incoming to Software Bugs
>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). The subinitial (and subfinal) index code only helps if the indexed strings are unique within their first (or last) 4 characters. For the data you're using, this condition doesn't apply; the majority of your entries all fall into the same index slot and so they must be checked individually. This same substring indexing logic has been in place for a long time, which is why the same behavior is present in 2.0, 2.1, and probably even 2.2, in all the backend types that support indexing (back-ldbm, back-bdb, back-hdb). -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
changed state Open to Feedback
changed notes changed state Feedback to Closed
changed notes changed state Closed to Test
changed notes changed state Test to Closed moved from Software Bugs to Software Enhancements
moved from Software Enhancements to Archive.Software Enhancements
Not a bug. Aspect of frontend indexing design. Redesinged in HEAD, for release in 2.3