Dear Howard,

Thank you for your prompt reply.

This is certainly no bug in idl_intersection(), it is an optimizatio that makes subsequent intersection operations faster. As such, your suggested fix is wrong.

I understood the line 1094-1099 part of idl.c was implemented to optimize subsequent intersection oprations. On the other hands, in this case, bdb_idl_intersection(C,D) (as I described before) returns the range-type candidate set despite its having only two elements. Then, by subsequent bdb_idl_union() with A (list-type: the number of elements=296, minID=296,maxID=858689), the candidate set becomes very huge. #bdb_idl_union() seems to change the candidate set into "range-type" #if one of the two sets is a "range-type".

The impact of removing the optimization of bdb_idl_intersection() is only that subsequent bdb_idl_intersection() oprations become slower in certain cases? If the aforementioned optimization becomes effective when the number of the element is more than certain threshold number(ex.1024), I would like to change bdb_idl_intersection() like that:

ex) 1091 if ( BDB_IDL_IS_RANGE( b )

1092 && BDB_IDL_RANGE_FIRST( b ) <= BDB_IDL_RANGE_FIRST( a )

1093 && BDB_IDL_RANGE_LAST( b ) >= BDB_IDL_RANGE_LAST( a ) ) {

1094 if (idmax - idmin + 1 == a[0] && a[0] > 1024)

1095 { 1096 a[0] = NOID;

1097 a[1] = idmin;

1098 a[2] = idmax;

1099 } 1100 goto done;

1101 }

The issue occurs in the environment of our user and makes some trouble because of the slow response of the ldapsearch. So, I would like to find some fix of the issue.

If you want to suggest a fix, you should look at idl_union() instead.

Thank you for your advice. I'll also try to check bdb_idl_union().

If you have other good idea to fix the issue, could you let me know?

Best Regards,