http://www.ibase.ru/dataaccesspaths/#chapter123
Для вычисления MIN/MAX в подавляющем большинстве случаев она будет равна высоте B+
дерева (поиск первого ключа) плюс единица (фетч страницы). Стоимость такого доступа
считается принебрежительно малой величиной, так как на практике описанное вычисление
MIN/MAX всегда будет быстрее альтернативных вариантов. Для оценки же стоимости индексной
сортировки надо учесть как количество и среднюю ширину ключей индекса, так и
кардинальность битовой карты (если таковая есть), а также иметь представление о факторе
кластеризации (clustering factor) индекса – коэффициенте соответствия расположения ключей
физическим номерам записей.
Я правильно понимаю, что для поиска следующей записи не надо проходить дерево заново от
корня, так что количество фетчей на запись меньше, чем 2 + <глубина индекса>?

PS: В слове "пренебрежительно" опечаточку хорошо бы поправить...
Posted via ActualForum NNTP Server 1.5

Симонов Денисэто будет зависеть от того будут ли вытеснены индексные страницы.

Количество фетчей - не зависит. В этом их разница от чтений.
Posted via ActualForum NNTP Server 1.5

Симонов ДенисТо есть к корню действительно нет смысла возвращаться

Так-то оно да, но только если между двумя фетчами с листовой страницей кто-то поигрался и
она исчезла или разделилась на две... Как, собственно, метод доступа находит "следующий ключ"?
Posted via ActualForum NNTP Server 1.5

dimitrсохраняется номер страницы и позиция последнего найденного ключа.

То есть идея одним махом собирать сразу все ключи со страницы в список может сэкономить
всего один фетч.
Posted via ActualForum NNTP Server 1.5