Jason Dusek writes:
I'm curious because DNs are the only allowed key for the
referential
integrity. If they are searched using string operations, that would
be pretty slow relative to shorter strings (UID) or plain old Int
values.
If you need a search for an attribute to be fast, you should index
that attribute if you use back-bdb/hdb. (And I presume, do something
equivalent if you use back-sql.) This applies regardless of whether
the search is done by a client or an overlay - like refint or unique.
DN-valued attributes like secretary and seeAlso are no different from
other attributes in this respect.
bdb/hdb indexing works on a hash of the attribute value. After scope
and indexing (if any) has narrowed down the search, the resulting
candidate entries are checked against the filter with the ordinary
matching rules.
Are DNs optimized in any way, for lookup or storage? Or are
they merely packed into strings and searched
lexicographically?
For DN-valued attributes, see above. For the entry DNs themselves, bdb
and hdb maintain a dn2id file which maps DN (bdb) or parent+RDN (hdb) to
entry-ID.
--
Hallvard