Dmitri Kuzmenko wrote:
Ты вот все время напираешь, что "а если одна запись".
Я уже говорил, что действительно, оптимизатор теоретически
должен бы при определенной селективности столбца B
в
select * from table
where b = 5
order by a
игнорировать индекс по A.
Но пока, вроде, не игнорирует. Другое дело, что
при проходе по индексу A он не лезет проверять записи на b=5,
а проверяет ту самую битовую маску по B сразу же. И только если
совпало, выдает запись "на выход". Так что IO все же экономится.
Это понятно. У меня вызывает вопросы выбор между планами
PLAN (EVENTS ORDER IDX_A INDEX (IDX_A, IDX_B))
и
PLAN SORT (EVENTS INDEX (IDX_A, IDX_B))
Записей в таблице может быть очень много. Соответственно индекс большой
тоже по размеру. Если битовая маска INDEX (IDX_A, IDX_B) даёт мало записей,
то SORT очевидно будет предпочтительнее. В этой ситуации оптимизатор должен
принимать решение уже в процессе выполнения запроса, а не в момент prepare.
Ведь в принципе нетрудно одновременно с построением битовой маски посчитать
количество записей, которые попало в неё.
Но раз этого нет, то мне надо план как то захардкодить уже сейчас.
