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,
--
*********************************************
Yoshinori Nishino
NEC Soft, Ltd.
E-MAIL: nishino-yoshin...@mxc.nes.nec.co.jp
*********************************************
