[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back-bdb flaw
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.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/