Re: memory usage of dn attributes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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