Michael Ströder wrote:
Howard Chu wrote:
Seems like the best fix is to deprecate back-bdb and only use back-hdb from now on.
But I vaguely remember that back-hdb has higher memory consumption.
Eh? back-hdb has a smaller memory footprint, as well as a smaller on-disk footprint.
Maybe you're thinking of the original design in 2.1 http://www.openldap.org/lists/openldap-devel/200303/msg00055.html
which changed quite a bit since then.
Thinking about it some more, we can still salvage back-bdb, but it will require a change in the dn2id index format. The only thing that bothers me about this is that once you start down the path of making "sensible" changes to back-bdb's dn2id format, you eventually arrive at back-hdb anyway, so again, is it really worth the effort...
Anyway, the solution I'm thinking of is to reverse the RDN order in the dn2id index keys. (I.e., use X.500 order.) This way we can use BDB range lookups to find children/siblings of entries. That will give us a quick method of validating the OneLevel index. (The next logical step is of course to eliminate the OneLevel index because it's superfluous once you organize the RDNs this way. But we can stop short of that, no point in repeating the development of back-hdb yet again.)