Hi there:
I'm trying to understand how ldap filters work. Based on this simple logic expression:
EXPR_1 (or) EXPR_2
if EXPR1 returns TRUE, will slapd still try to evaluate EXPR2? or will slapd evaluate EXPR2 anyway even if EXPR_1 is true?
I think that while the ldap filter is bigger then performance is worse, right?
could somebody explain me a little about this logic of evaluation in ldap filters?
Thanks
Jason Voorhees wrote:
Hi there:
I'm trying to understand how ldap filters work. Based on this simple logic expression:
EXPR_1 (or) EXPR_2
if EXPR1 returns TRUE, will slapd still try to evaluate EXPR2? or will slapd evaluate EXPR2 anyway even if EXPR_1 is true?
I think that while the ldap filter is bigger then performance is worse, right?
could somebody explain me a little about this logic of evaluation in ldap filters?
As far as I understand the code, test_filter() stops filtering, returning success, at the first occurrence of TRUE.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Thanks. That allows me to build complex filters using OR logic without being worried about performance.
Thanks again, bytes!
Pierangelo Masarati escribió:
Jason Voorhees wrote:
Hi there:
I'm trying to understand how ldap filters work. Based on this simple logic expression:
EXPR_1 (or) EXPR_2
if EXPR1 returns TRUE, will slapd still try to evaluate EXPR2? or will slapd evaluate EXPR2 anyway even if EXPR_1 is true?
I think that while the ldap filter is bigger then performance is worse, right?
could somebody explain me a little about this logic of evaluation in ldap filters?
As far as I understand the code, test_filter() stops filtering, returning success, at the first occurrence of TRUE.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it
Jason Voorhees wrote:
Thanks. That allows me to build complex filters using OR logic without being worried about performance.
of course, if you build a complex filter with a long list of OR-ed AVAs, all the indexed ones will be considered when listing candidates.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Jason Voorhees writes:
Thanks. That allows me to build complex filters using OR logic without being worried about performance.
Sorry, no. First slapd must locate all entries to compare with the filter. For that it uses indexes. First it uses the DN index, to find just the entry IDs of just entries in the search scope.
Then if all the ORed components are indexed, it can narrow this list further down by only checking entries that match one of the filter components. OTOH if one of the ORed components is not indexed, slapd cannot narrow down the entry candidate list further.
Finally it checks each candidate entry against the filter. When checking an entry, slapd can indeed stop the first time an OR yields TRUE. Or the first time an AND yields not-TRUE (FALSE or Undefined).
mmm, I'm planning to build something like this in /etc/saslauthd.conf:
(&(mail=%U@%d)(|(&(objectClass=VirtualMailaccount)(accountActive=TRUE))(objectClass=VirtualMailAlias)))
that tries to locate two kind of entries:
1. mail=user@domain,vd=domain,o=hosting,dc=myldap,dc=com (VirtualMailAccount)
2. cn=postmaster,vd=domain,o=hosting,dc=myldap,dc=com (VirtualMailAlias)
There could be hundreds or maybe thousand of entries of type (1), but only 1 entry of type (2). The filter shown above is used to authenticate users trough saslauthd. So 95% of times users authenticate using type (1), but sometimes I would need to authenticate as 'postmaster' using type (2).
I was worried about performance because using (objectClass=VirtualMailAlias) with OR just for a unique account in my domain.
Would I get much better performance if remove (objectClass=VirtualMailAlias) from the filter? Do you believe that the performance impact will be big?
Hallvard B Furuseth escribió:
Jason Voorhees writes:
Thanks. That allows me to build complex filters using OR logic without being worried about performance.
Sorry, no. First slapd must locate all entries to compare with the filter. For that it uses indexes. First it uses the DN index, to find just the entry IDs of just entries in the search scope.
Then if all the ORed components are indexed, it can narrow this list further down by only checking entries that match one of the filter components. OTOH if one of the ORed components is not indexed, slapd cannot narrow down the entry candidate list further.
Finally it checks each candidate entry against the filter. When checking an entry, slapd can indeed stop the first time an OR yields TRUE. Or the first time an AND yields not-TRUE (FALSE or Undefined).
Jason Voorhees writes:
mmm, I'm planning to build something like this in /etc/saslauthd.conf:
(&(mail=%U@%d)(|(&(objectClass=VirtualMailaccount)(accountActive=TRUE))(objectClass=VirtualMailAlias)))
I don't know saslauthd, but: Will (mail=%U@%d) match at most one entry? Then if you have an 'eq' index for 'mail', slapd won't need to compare more than one entry with the filter. Since the 'or' filter is inside the 'and', it won't be a problem in this repect.
that tries to locate two kind of entries:
- mail=user@domain,vd=domain,o=hosting,dc=myldap,dc=com
(VirtualMailAccount)
If you do a baseobject search at that baseDN, that's also just one entry to examine.
- cn=postmaster,vd=domain,o=hosting,dc=myldap,dc=com
(VirtualMailAlias)
There could be hundreds or maybe thousand of entries of type (1), but only 1 entry of type (2).
If mail is indexed, that's fine.
The filter shown above is used to authenticate users trough saslauthd. So 95% of times users authenticate using type (1), but sometimes I would need to authenticate as 'postmaster' using type (2).
I was worried about performance because using (objectClass=VirtualMailAlias) with OR just for a unique account in my domain.
Would I get much better performance if remove (objectClass=VirtualMailAlias) from the filter? Do you believe that the performance impact will be big?
No, not much.
Hallvard B Furuseth escribió:
Jason Voorhees writes:
mmm, I'm planning to build something like this in /etc/saslauthd.conf:
(&(mail=%U@%d)(|(&(objectClass=VirtualMailaccount)(accountActive=TRUE))(objectClass=VirtualMailAlias)))
I don't know saslauthd, but: Will (mail=%U@%d) match at most one entry?
Yes, it always match only one entry per search operation.
Then if you have an 'eq' index for 'mail', slapd won't need to compare more than one entry with the filter. Since the 'or' filter is inside the 'and', it won't be a problem in this repect.
Yes, I mantain 'eq' index for 'mail' atttributes.
that tries to locate two kind of entries:
- mail=user@domain,vd=domain,o=hosting,dc=myldap,dc=com
(VirtualMailAccount)
If you do a baseobject search at that baseDN, that's also just one entry to examine.
- cn=postmaster,vd=domain,o=hosting,dc=myldap,dc=com
(VirtualMailAlias)
There could be hundreds or maybe thousand of entries of type (1), but only 1 entry of type (2).
If mail is indexed, that's fine.
The filter shown above is used to authenticate users trough saslauthd. So 95% of times users authenticate using type (1), but sometimes I would need to authenticate as 'postmaster' using type (2).
I was worried about performance because using (objectClass=VirtualMailAlias) with OR just for a unique account in my domain.
Would I get much better performance if remove (objectClass=VirtualMailAlias) from the filter? Do you believe that the performance impact will be big?
No, not much.
Thanks a lot Hallvard, bytes! :)
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Jason Voorhees -
Pierangelo Masarati