> А в памяти и не надо. См. WriteFileGather API (в posix'е, кстати, > оно на порядок удобнее).
Вот ... падла. Я про Рихтера. Влад, спасибо. Я и не знал про эту пару функций. > > Читать-то все равно только по одной странице за раз надо ? > > Почему ? А что я могу за два раза прочитать? Если только сдвоеные страницы для каталога индекса использовать... А ведь в натуре, блин... чего я на одной странице, как дэбел, все ютюся. Пляяяяяя........ Слушай, я вот все не фтыкаю. Как вы работает на 75 страницах классика? Это же ахтунг натуральный. > > > > Вторая - Б-деревья. > > > > Тут будет не более 4-х на твоих объёмах > > > При 4 килобайтной странице ... ???? У меня 4-х байтный идентификатор > > страницы. Ключ, считай, 16-байтный. Данные, которые нужно привязаны к > > ключу - 8 байт (это тот же ID, только для пары целиком). > > Я вообще-то FB-шные индексы имел в виду и страницу в 8-16К. Последовательно идущие две-четыре страницы? Влад, если я начал думать в правильную сторону, то твои подсказки - это первая реальная помощь за все это время. Великого LOA, который сподвигул меня к OVERLAPPED-операциям, в расчет не берем - он вне конкуренции :) > Кури btr.cpp - как там все сделано в смысле блокировок. При вставке > в индекс никогда не блокируется более одной страницы одновременно, даже > во время расщепления. При удалении блокируется до 4-х страниц, из них на > запись только одна. Всё в строгом порядке, есс-но, так что дедлоков быть > не может Пасибо! > > > Кстати - префиксная компрессия ключей в этом смысле очень даже > > > рулит. Хотя кодировать это - ужас один > > > Я дальше отбрасывания ведущих нулевых байт для DST не собирался > > "сжимать". Поэтому и говорил про 4 байта (при 8 максимум). > > А ты обрати внимание на среднюю длину ключа в индексе FB и на кол-во > занимаемых страниц. Тебе понравится ;) Не сомневаюсь :) > > ... Значит все таки практикующие акушеры рекомендуют Б-дерево. > > Шо знаем, то и рекомендуем :) Еще раз, большое человеческое спасибо! Коваленко Дмитрий.
