Howard Chu wrote:
In our case, back-bdb and back-hdb basically have identical search
performance. So there's really no downside to supporting fast ModifyDN
in back-hdb, and we've been intending to phase out back-bdb...
I now that theory != real life, but for a search which is not based on
the DN, I can't see how a double lookup ( one for the entry + one for
the DN) could be as fast as a simple one, assuming that you still need
to provide the DN.
For searches based on DN, performances should be identical, as you will
have to read the DN anyway..
So for search, theory says : storing the DN within the entry should be
faster (if you each the cache), unless you have a limited memory size
and have to hit the disk more. But even then, I'm not sure that the
difference in performance would be noticable, unless you have hundred of
millions entries and not a lot of memory.
Is my theory wrong ?
Now, what would be very interesting is to gather real life data about
what people _really_ do on their servers, with stats :
- How many SearchRequest // Modify // Add // Delete // ModifyDN
- for SearchRequests, ratio between DN based searches // attribute based
searches.
Thanks Howard, as usual, your insights are always good to have ! (when
you will hate Java less, let us know, we have a warm and comfortable
place for you at Directory :)
Heh heh... Still enjoying the work you guys have done with
DirectoryStudio. You may find me writing java code there sooner or
later...
That would be a great pleasure ! I'm pretty sure that having an OpenLDAP
admin plugin would be a big plus !
Thanks !
FYI, LdapConference won't occurs this year.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
