[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: filter preprocessing for performance improvement
Eric Irrgang wrote:
I wonder if it might be reasonable for the slapd frontend to do some
preprocessing of search filters to recognize no-ops and such. Most
specifically, any search filter of the form (&(objectclass=*)(filter2))
can be reduced to (filter2), right?
(objectclass=*) is already a no-op in back-bdb/back-hdb. I made that
optimization back in November 2001.
So yes, it's a nice idea, been there, done that.
I have a problem in that the first time someone performs a search for
'objectclass=*' after slapd is restarted, the server is really bogged
down for a while. Once the search has completed once, this is not a
problem. I assume that's due to the IDL cache. However, I currently
have to keep the server unavailable after restarting slapd for upwards
of half an hour while I do an 'objectclass=*' search the first time.
Changing the behavior of (objectclass=*) isn't going to make any
difference. If you specify a filter that is too broad, then slapd has to
trawl through every entry in the DB because every entry satisfies the
condition.
I suppose a followup might be some preevaluation of ACLs before
performing easily-recognized searches. For instance, the backend should
not have to cope with a search for objectclass=* if the user doesn't
have read access to anything as is often the case with an anonymous bind.
That's not a fair assumption.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/