Re: Question on EQUALITY on index and schema definition

Mark Reynolds <mreynolds@xxxxxxxxxx> · Mon, 5 Aug 2019 08:57:40 -0400



    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