On Tuesday, November 27, 2018 5:13:41 PM CST Howard Chu wrote:
Derek Zhou wrote:
> Unfortunately, down time is even worse than slow.
> I wish OpenLDAP has an integrated search and delete operation, like delete
> entries based on a search filter, all executed in the same transaction in
> the server. That should be more efficient than doing search and delete
> from the client side because the B+ trees are just traversed once. Also
> the server can impose size limit on how many entries can be deleted in
> one go, just like the search, to avoid someone hogging the server.
> For the LDAP gurus here, the above idea should be technically possible,
In normal operation, as opposed to simple experimentation, why do you
actually need to delete a large number of entries quickly? If you just need
to make them unavailable to a bunch of clients, you can first do a subtree
rename to move them out of the way, and then delete incrementally at
If the database is going to occupy significant amount of diskspace, the sys
admin in me will feel safer if I can delete fast. A file system can do that, a
SQL database can do that. Imagine a user application is running wild and
injecting a lot of junk data, being able to delete fast is crucial to keep the
system up til the culprit is identified and killed. This scenario has happened
to me several times, just not with a LDAP database.