[Date Prev][Date Next]
I use a slightly back-revved version of OpenLDAP 1.2 (I had been
cvs updating it to release engineering, so I'll say around 1.2.6)
I mention this in case my results are due to having a retro version.
My database has hundreds of thousands of entries in it.
If I do a search with a filter such as "uid=x", then I get a
fast response. However, if I make the filter a little more
complex, and search "&(uid=x)(deleted=1)", it gets extremely
slow. In fact, the filter "(uid=x)" is fast, but the filter
"&(uid=x)" is very slow. Apparently, this last filter searches all
ids. Also, it makes me wonder how "&(deleted=1)(uid=x)"
would be treated. "Deleted" is not an indexed attribute, whereas
"uid" is. Therefore, you would not want to make the mistake of
searching allids for "deleted=1" before applying the entire filter.
I heard mention of indexing being re-written for version 2, and
hopefully the new stuff will optimize much better. If I can help,
I offer my support (for right now, that probably means testing the
Lastly, a suggestion for an index (I might have to write this myself):
I'd like to be able to have the filter "attribute=z*" use an index.
The eq index (if it is a btree) would have the information necessary
to satisfy this request quickly, but apparently it does
not. Specifically, by the way, I've been using LDBM with BerkeleyDB.
Since the search code is backend-specific, there may be new backends
in OpenLDAP 2.0 that are more efficient, such as bdb2.