Ну память всегда быстрее винчестера, это и доказывать не нужно :) Хотя мне кажеться одним из главных достоинств РСУБД должна быть как раз эффективная работа с данными, не умещающимися в кэш.

Бестолку сравнивать ASA >=8 и ASA <=7 - у них абсолютно разные оптимизаторы и принципы работы. Начиная с 8-версии была введена куча алгоритмов соединений через индексамы и хэш-таблицы, аггрегатных и т.д. Даже переориентация на большое кол-во одновременно работающих сессий внесла свои коррективы в работу оптимизатора.

VovakaМне нравится вот такой пример

большая таблица, индекс по полю dt

select min(dt) from table1 - влет
select max(dt) from table1 - влет
select max(dt), min(dt) from table1 - уходит в table scan надолго ...
Ну а как бы Вы поступили на месте оптимизатора, уже изначально потребовав прямое и обратное сканирование по индексу ? Дважды сканили индекс, забирая весь доступный кэш у других сессий и дважды блокируя все записи таблицы ? Если Вы согласны на двойное сканирование, то кто мешает написать вот так:

При оценке не только скорость учитывается, но и требование к ресурсам на выполнение запроса, текущий уровень изоляции, блокировки, ширина таблицы, типы существующих индексов, наличие кластерного индекса и надо думать многое другое, так как первоочередная задача РСУБД не форсированно выполнить запрос одной сессии, а держать сервер на плаву при работе множества подключений на чтение и запись. Здесь пример легко решается мною вышеуказанным методом. Для более сложных случаев в ASA не зря введен алгоритм LATERAL и другие, позволяющие проектировщику разруливать такие ситуации и неявно управлять действиями оптимизатора, без жесткого навязывания индексов.

P.S. Если на такой запрос навязать индекс, то в плане запросов использование индекса будет гораздо затратнее, чем Table Scan. Обьясняется это тем, что все дерево перебрать всегда дольше, чем линейно считать таблицу. Плюс во время сканирования таблицы не востребуется кэш, что и влияет на выбор такого алгоритма. С учетом того, что алгоритм намеренно задается как "долгий" - так или иначе перебор всей таблицы, думаю в таких случаях ответственость за время и эффективность выполнение запроса несет только проектировщик БД, который и должен изначально написать "правильный" запрос, приводящий к наиболее эффективному составлению плана оптимизатором.