Re: Question on EQUALITY on index and schema definition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 8/4/19 9:55 AM, Lutz Berger wrote:
Hello,

I've come across a web site
that claims that an "equality index" is only allowed for attributes
that have "EQUALITY" in their description, "otherwise terrible things
will happen".

For example
>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xxx NAME 'abCLZ'  EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )

For the sake of correctness, I've tried to build an equality-index for an attribute missing such description, e.g.

>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xyz NAME 'abID'  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
     

So what is happening is that the first example has a "matching rule" defined:   EQUALITY caseIgnoreMatch.  If you define such an attribute with this syntax you MUST have an equality index for that attribute.  Otherwise the server has to manually perform this matching - which is VERY expensive.  Hence why you see an etime of 26 seconds.  Once its indexed for equality the matching rule can efficiently be processed.  But you do not NEED to use this matching rule: EQUALITY caseIgnoreMatch, unless you have a requirement for it.  But you should always index your attribute for how you plan to use it.  In this case you are doing an equality search:  <ATTR>=<some exact value> so you would want an equality index (regardless of the presence of a matching rule).

HTH,

Mark


Withour EQ-Index:
[root@ur1 slapd-ur1devims]# fgrep "conn=34" access
[03/Aug/2019:14:21:00 +0200] conn=34 fd=65 slot=65 connection from 192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:21:00 +0200] conn=34 op=1 SRCH base="ou=users,c=de,o=creditreform" scope=2 filter="(abID=777777777022544)" attrs=ALL
[03/Aug/2019:14:21:26 +0200] conn=34 op=1 RESULT err=0 tag=101 nentries=1 etime=26 notes=A
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 UNBIND
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 fd=65 closed - U1
[root@ur1 slapd-ur1devims]#

With EQ-Index:
[root@ur1 slapd-ur1devims]# fgrep "conn=35" access
[03/Aug/2019:14:24:18 +0200] conn=35 fd=65 slot=65 connection from 192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 SRCH base="ou=users,c=de,o=creditreform" scope=2 filter="(abID=777777777022544)" attrs=ALL
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 UNBIND
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 fd=65 closed - U1

My question is now, is the EQUALITY part of the schema description really necessary
for building equality-indexes on attributes, since I couldn't reproduce any obvious
problem.


From the access pattern I see in the access log, building such an index is
definitely beneficial in sense of performance.

Thanks for your efforts!

Best regards,
  Lutz


--
Dipl.-Inform. Univ. Lutz Berger
Email: lutz.berger@xxxxxxxxxxxx


_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
-- 

389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux