had the same problem years ago and the patch worked for me. As I
understood, this special problem exist in mdb too
Thats one reason, because I did not switch till now.
2013/5/24 Howard Chu <hyc(a)symas.com>:
Chris Card wrote:
>>>> Any ideas?
>>> Increase the IDL range. This is how I do it:
>>> --- openldap-2.4.35/servers/slapd/back-bdb/idl.h.orig 2011-02-17
>>> 16:32:02.598593211 -0800
>>> +++ openldap-2.4.35/servers/slapd/back-bdb/idl.h 2011-02-17
>>> 16:32:08.937757993 -0800
>>> @@ -20,7 +20,7 @@
>>> /* IDL sizes - likely should be even bigger
>>> * limiting factors: sizeof(ID), thread stack size
>>> -#define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17
>>> +#define BDB_IDL_LOGN 17 /* DB_SIZE is 2^16, UM_SIZE is 2^17
>>> #define BDB_IDL_DB_SIZE (1<<BDB_IDL_LOGN)
>>> #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+1))
>>> #define BDB_IDL_UM_SIZEOF (BDB_IDL_UM_SIZE * sizeof(ID))
>> Thanks, that looks like it might be the issue. Unfortunately I only see
>> the issue in production, so patching it might be a pain.
> I've tried this change, but it made no difference to the performance of
> the query.
You have to re-create all of the relevant indices as well. Also, it's always
possible that some slots in your index are still too big, even for this
You should also test this query with your data loaded into back-mdb.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/