Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

S>> Поиск на == и <= используют один и тот же алгоритм половинного деления по индексу.

V>Это при запросе одиночного значения.
V>При джоинах на индексе этот алгоритм для каждой строчки выполняется не в "чистом" виде, а лишь по интервалу от предыдущего найденного значения (соединяются-то сортированные наборы), т.е. в случае простого join== почти всегда сводится к операции перехода на следующую строку, если текущая строка основного ключа не подошла строке внешнего ключа.

Да и это ерунда, так ка данные находятся в кэше. Это малая величина по сравнению с основным временем поиска.

S>>Сложность одинакова. Только при курсе на каждый день нужно заполнять все дни (выходные, праздники когда торги не проходят), что увеличивает размер таблицы и индекса

V>Ну как же одинаковая, если в случае нестрого равенства надо сравнивать даты у двух соседних строчек? ))
V>Это совсем другой алгоритм перебора строк.

Еще раз я для чего тебе ссылку то давал. При поиске останавливается на месте которое меньше или равно.
Почитай алгоритм. Он кстати используется и для вставки если ключ не найден.
V>Если первый алгоритм всегда присутствует в базе выполненым на "железячном" уровне, то второй выполняется по классике жанра — через честные параметрические сканы таблиц по индексам и запуски "скриптов" проверки условий (привет метаинформации и всему, что с ней связано), бо таких различных условий, отличных от базовых inner и outer join — их потенциально бесконечный комбинаторный набор.

Угу. Проблема может быть только при использовании Хэш таблиц. Но если ты посмотришь на результвты там разница в 4 раза максимум. Но хэш таблицы применимы только для небольших размеров данных