> As for working set size, that is always merely the height of the B+tree.
This statement makes no sense to me. Are you using a different definition of "working set" than the rest of us? A working set size is application and access pattern dependent.
> It will always be far more efficient than any other DB under the same conditions
That depends on how broadly or narrowly one defines "same conditions" :-)
That’s a bold claim. Are you saying that LMDB outperforms every other database on the same hardware, regardless of access pattern? And if so, is there proof of this?
Since the first question of my two-part inquiry not explicitly answered in the affirmative: To be absolutely clear, you are claiming, in writing, that LMDB outperforms every other database there is, regardless of access pattern, using the same hardware?
LMDB is optimized for read-heavy workloads. I make no particular claims about write-heavy workloads.
Because it's so efficient, it can retain more useful data in-memory than other DBs for a given RAM size. For DBs much larger than RAM it will get more useful work done with the available RAM than other DBs. You can examine the benchmark reports linked above, they provide not just the data but also the analysis of why the results are as they are.
This statement makes no sense to me. Are you using a different definition of "working set" than the rest of us? A working set size is application and access pattern dependent.
> It will always be far more efficient than any other DB under the same conditions
That depends on how broadly or narrowly one defines "same conditions" :-)