-----BEGIN PGP SIGNED MESSAGE-----
Volker Lendecke schrieb:
> Right now I'm looking at putting the registry into ldb. One
> operation that I need fast is a LDB_SCOPE_ONELEVEL search to
> enumerate keys and values. Looking at the ldb_tdb code to me
> it appears that this boils down to a full scan of the ldb.
> For a large registry this might become a performance issue.
> Is that assumption right? And if not, what do I have to do
> to get around this tdb scan?
currently you can't do anything and for the the LDAP like use,
most searches are indexed.
I've also thought about this and wanted to extend TDB to support
multiple virtuell tables. On top of that I would like to implement
a ldb backend that stores data hierarchical, and let non indexed search
walk the tree started at the basedn.
With this we can easy implement 'naming contexts'/'directory partitions'
correctly, NC_HEADS are identfied by a flag in the 'instanceType'
attribute. And based on that we can easy implement onelevel search,
subtree searches, search limited to a naming context including
generating the correct referrals when we reach a child naming context
This would also solve the case were we need to return noSuchObject, when
the basedn is missing, instead of returning 0 search results.
But the problem is that it would take a view weeks or months to
implement, because we need to make sure that it will be fast as the
current ldb_tdb for the indexed searches.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----