Date: Thu, 14 Jan 2010 16:45:32 +0100 From: Andrey Ivanov <andrey.ivanov(a)polytechnique.fr&gt;

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.