ldb speed

[simo]

On Mon, 2006-10-30 at 10:57 -0500, Michael B Allen wrote:
> On Mon, 30 Oct 2006 14:53:35 +0000
> simo <idra at samba.org> wrote:
> 
> > On Tue, 2006-10-31 at 00:49 +1100, Luke Howard wrote:
> > > >> Why would the member attribute change if the group is renamed?
> > > >
> > > >*memberOf* sorry
> > > 
> > > You may not want to store this. pp20-21
> > > 
> > > http://www.openldap.org/conf/odd-wien-2003/luke.pdf
> > > 
> > 
> > I've seen this before, but may I ask why do you prefer to resolve these
> > attributes at search time instead of at add/modify/delete/rename time?
> 
> So you don't have to update memberOf (and any other back-links) of DN
> attrtibutes that change.

Yes, this is understood, but then you have to resolve them for each
search. So the question is why paying the cost multiple times during
searches and not once when the membership is changed ?

> > Searching is the most common operation, so optimizing for search is
> > always better than any other case.
> > 
> > So let's suppose you have this 10000 users group, do you end up making
> > 10000 queries to resolve all the 10000 UUID reference links?
> 
> 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.

> 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.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org