389-devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > Date: Thu, 14 Jan 2010 16:45:32 +0100 > From: Andrey Ivanov <andrey.ivanov@xxxxxxxxxxxxxxxx> > 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/ -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
