[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP profiling/performance



On Wed, Jan 03, 2001 at 03:08:56PM -0800, Kurt D. Zeilenga wrote:
> At 06:01 PM 1/3/01 -0500, Ben Collins wrote:
> >On Wed, Jan 03, 2001 at 02:28:29PM -0800, Kurt D. Zeilenga wrote:
> >> 
> >> index uid eq
> >> 
> >
> >I have:
> >
> >index uid eq,pres,sub
> >
> >So, no that's not the problem.
> 
> Then it's more likely the code is broke.

Well, I found the problem, but I'm unsure how to fix it. The code in
back-ldbm/filterindex.c starts out with 11124 candidates. It then calls
to filter that down to those matching the filter. Of course in this case
it matches, and we see:

        for ( f = flist; f != NULL; f = f->f_next ) {
                if ( (tmp = filter_candidates( be, f )) == NULL &&
                    ftype == LDAP_FILTER_AND ) {
                                Debug( LDAP_DEBUG_TRACE,
                                    "<= list_candidates NULL\n", 0, 0, 0 );
                                idl_free( idl );
                                return( NULL );
                }

                tmp2 = idl;
                if ( idl == NULL ) {
                        idl = tmp;
                } else if ( ftype == LDAP_FILTER_AND ) {
                        idl = idl_intersection( be, idl, tmp );
                        idl_free( tmp );
                        idl_free( tmp2 );
                } else {
                        idl = idl_union( be, idl, tmp );
                        idl_free( tmp );
                        idl_free( tmp2 );
                }
        }

The call to filter_candidates() returns "1" valid entry. This in turn
calls idl_union() to join it with the rest (the original 11124), when it
should actually replace the original set. I'm not sure how to fix this
without affecting the rest of the code. I'll keep looking, but hopefully
you can get back about it before I finish :)

Somehow it seems that list_candidates() is getting called with an ftype
of LDAP_FILTER_OR, which I'm not sure where it comes from. I would
assume that this should be LDAP_FILTER_AND.

If I hardcode this to replace rather than join, I get a quick response
(but obviously that's broken code).

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'