>Что мешает прочитать мануал по BerkeleyDB и перестать фантазировать?
>
>Для btree и hash там используется постраничная блокировка. Ни о каком блокировании
>всей базы речи нет.

Постраничная блокировка - это не атомарная операция и в больших БД страница может стать о(sizeof(DB)) - 'о'-малое от размера бд, те фактические своим количеством сэмитировать блокировку ячейки. Если даже поставить лимит кол-ва страниц, то на тех-же больших бд возникнет эффект схожий с блокировкой все БД. Предлагаю не выпендриваться и перестать перефразировать мои слова. + мозг подключять при чтении документации.

>Кстати, там же речь идет о сравнении производительности hash и btree. Резюме
>такое, что в зависимости от размера базы это немонотонная функция. Вначале
>(пока база влезает в оперативную память) - без разницы, потом узким
>местом становится IO и hash сливает, а потом начинает сказываться размер
>метаданных, который больше у btree, и в итоге на самых больших
>базах выигрывает hash. Разумеется, если locality не важна, а нужен только
>точный поиск по ключу и важна производительность.

Твою ###########! Хеш будет сливать только при малом размере БД (очень малом). При всех остальных, даже если он целиком будет храниться на диске - он будет впереди. Другое дело реализация - можно обосраться и сделать даже самый быстрый алгоритм медленее банального перебора. Если берклидб в документации пишет, то, что ты выше рассказал - то это явно у них проблемы с реализацией.