ldb speed

Michael B Allen mba2000 at ioplex.com
Mon Oct 30 20:28:24 GMT 2006

On Mon, 30 Oct 2006 18:14:49 +0000
simo <idra at samba.org> wrote:

> > I'm not sure I understand whole thread very well but I don't think you
> > would need to resolve the UUID unless the DN of the object it points
> > to was to be returned in the search or the attribute (e.g. memberOf)
> > was used in the filter of the search. So unless you're searching for
> > memberOf's on 10000 users then no.
> Sure, I am referring to a serch on a group with 10000 members when you
> request the "member" attribute.

Since 'member' is the forward part of the link I would think you would
have direct access to it's DN.

Meaning you could store the DN and UUID with the member attribute and
put the UUID in a hash index where the UUID is the key and the attribute
is the datum.

That way retrieving the 'member' DN does not require a lookup and
retrieving the 'memberOf' DN requires a hash index lookup but that's
lightening fast (not to be confused with a btree index). And if the DN
of the member changes no additional work is required. The hash index
lookup returns an object from which you have direct access to the DN.

Actually, unless you can easily get from an attribute to it's owner I
guess the datum of the hash index might need to be the group object since
'memberOf' is the group DN.

Not that I'm a database guru but I did stay at a Holiday Inn last
night :->

> > Also, resolving the UUID should be no more costly than a hash index
> > lookup but I don't know anything about ldb so this is theory.
> Actually we index by DN, so for ldb UUID->DN means traversing the whole
> DB.
> We could resort to some trick to store a custom index for fast LINK
> lookup tough.

I would think you'd need hash indexes all over the place for this sort
of thing (e.g. lookup attribute syntax defs).


Michael B Allen
PHP Active Directory SSO

More information about the samba-technical mailing list