[389-devel] Please review: Allow modrdn to move subtree and rename non-leaf node

[Howard Chu]

389-devel-request at lists.fedoraproject.org wrote:
> Date: Thu, 14 Jan 2010 16:45:32 +0100
> From: Andrey Ivanov <andrey.ivanov at polytechnique.fr>

> Here are some questions or remarks that i still do have after this reading:
> Citation:
> -------------------
> This function entryrdn_index_read finds out the entry_id of the given
> DN sdn. It starts from the suffix in the entryrdn index following the
> child links to the bottom. If it is successful, the entry_is of the
> target node is set to the address that the argument id points to.
> -------------------
> 
> the previously used "entrydn" index and the corresponding function
> needed just one step(?) to find out the entry id from it's dn. Several
> steps are now needed with "entryrdn" index. You talk about an
> expensive entry_id - > dn conversion and you introduce the dn cache to
> take care of it. However you don't mention the expensive conversion dn
> -> entry_id (that was the role of entrydn.db4). As far as i understand
> the standard entry cache should help this conversion? And maybe this
> type of conversion is much less frequent than  entry_id - > dn?
> 
> It would be interesting to have an estimation of the performance loss
> (or gain?) due to this new entryrdn index for typical read/search
> operations - 3 to 5 levels of rdn in DIT... I think it can be done
> with ldclt in a similar way you've done it for ancestorid index.

Keep in mind that a DN to ID lookup generally only occurs once in any given
operation, while an ID to DN lookup occurs for every candidate entry in a
search. The latter is far more performance-critical. (Of course in OpenLDAP
back-hdb both lookups are performed with the same index, so the question is moot.)

Experience from developing back-hdb in OpenLDAP shows that all of the
downsides are more than cancelled out by the reduction in memory and I/O
footprint gained from the RDN-only index layout.

http://www.openldap.org/lists/openldap-devel/200112/msg00052.html
http://www.openldap.org/conf/odd-sfo-2003/howard-dev.html
-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/