https://bugs.openldap.org/show_bug.cgi?id=9735
--- Comment #4 from jtgrassie <[email protected]> --- > I thought about it as well, but then I count'd find any use-case for the other > (current) behavior. When the database can still grow, there is a clear > trade-off between performance and occupied storage. But otherwise, should > there > be a trade-off between performance and (non-)functionality? Could you please > think of an example where is it more desirable to return a failure than to > continue trying hard (to find some free space)? Thank you! The trade-off isn't really between performance and (non-)functionality, rather about performance vs growth rate concerns. This is because you either do a quick freelist search, and if not found, you can grow the environment (which is fast; the current solve), vs doing an aggressive (slow) fuller search (this proposed patch), before potentially growing. Hence if you don't really care about growth rate or are happy enough to occasionally do some maintenance when you do care (i.e. performing an `mdb_copy -c ...` to compact out the freelist), then the current approach is fine. But if you do care more about growth rate than performance, something like this patch is useful, because you're saying "hey, I don't care you might take a while looking through the freelist for free pages, I'd prefer that to growing unnecessarily". This is why I think this is a good candidate for an env open flag, so the user can decide which matters more to them. -- You are receiving this mail because: You are on the CC list for the issue.
