filter processing precedence
Hi All,
I just wondering how Sun Directory Server (or LDAP Server in general) process the filtering precedence and all.
If I have following filter format :
(&(customattr=*)(uid=johndoe))
how Sun DS process the filter ? Is it look for the "uid" first then look if the "customattr" contains "*" (presence)? or it will look from "customattr" then "uid".
I've seen the log file. The search for above format is pretty quick, thus, I guess it search using "uid" first which is indexed and "customattr" is not. Not sure though.
Is LDAP server configured to check the indexed attribute first (internally) before checking unindexed attribute in the filter?
Can someone confirm this ?
I've look at the "Performance Tuning Guide", they only mention about how the search use cache. Or maybe I miss the page.
thank you,
martin
[887 byte] By [
martinAZ3] at [2007-11-26 10:41:55]
# 1
There are some cases where Directory Server will do filter reordering.
Such as (&(uid < xxx)(uid >yyy)) will be reordered so that the server knows its yyy < uid < xxx.
Otherwise, filters are processed left to right.
Filter reordering happens before to know whether the index file exist or not.
Regards,
Ludovic.
# 2
Hi Ludo,
Okey, I see. So, I guess. It's slower (from client perspective) because the # of entries that need to be return.
I mean,
(customattr=*) will return 200,000 entries (let's say)
(&(customattr=*)(uid=johndoe)) will return 1 entries (let's say)
Second search will be fast (from client perspective), because it's only return 1 entry. But, all searches filter has to process (customattr=*) first. And it's fast .
Am I asking the "obvious" here ? :)
thanks so much,
martin
# 3
> Hi Ludo,
>
> Okey, I see. So, I guess. It's slower (from client
> perspective) because the # of entries that need to be
> return.
>
That's a factor...
> I mean,
> (customattr=*) will return 200,000 entries (let's
> say)
> (&(customattr=*)(uid=johndoe)) will return 1
> entries (let's say)
>
> Second search will be fast (from client perspective),
> because it's only return 1 entry. But, all searches
> filter has to process (customattr=*) first. And it's
> fast .
Depending on the nsslapd-allidThreshold value (check the doc for full explanation, but overall it's the limit after which its more expensive to maintain an index for the value than iterating through the DB entries).
The default is 4000.
So in the first case, the index will say ALLID (ie iterate through DB). The server will check each and every entry for the filter.
In the second case, the index will say ALLID for the first filter AND 1 entry for second filter, only 1 entry will be considered and returned.
I hope this helps.
Ludovic.
>
> Am I asking the "obvious" here ? :)
>
> thanks so much,
> martin
