Dmitri Kuzmenko wrote:
Записей в таблице может быть очень много. Соответственно индекс
большой тоже по размеру. Если битовая маска INDEX (IDX_A, IDX_B) даёт
мало записей, то SORT очевидно будет предпочтительнее. В этой ситуации
оптимизатор должен принимать решение уже в процессе выполнения
запроса, а не в момент prepare.
на основании чего сделан вывод, что оптимизатор "должен принимать
решение в процессе"? На этапе prepare известна кардинальность
таблиц и селективность индексов, и во время выполнения она не
меняется, да и скорректировать эти измерения никак.
Селективность - это средняя температура по больнице. Неизвестно сколько
попадёт в выборку в действительности с конкретными параметрами.
Плюс селективность для условий типа > или < оценивается очень грубо.
Ведь в принципе нетрудно одновременно с построением битовой маски
посчитать количество записей, которые попало в неё.
блин. это не количество записей. Это потенциальное количество
записей без учета версий. Даже если запись попала в битмап,
она может быть удалена. Или, у одной записи могут быть тыщи
версий, из которых или все или ни одной видны конкретной
транзакции, выполняющей запрос.
Видимость версий определяется только в момент чтения версий.
Я в курсе про версии. Это несущественно, т.к. версионность может только
уменьшить размер выборки, но никак не увеличить. Если в битовой маске
например 10 записей оказалось, то полюбому их будет меньше или равно 10.
p.s. я фигею, дорогая редакция. у нас (в ФБ) основная
"бяка" с оптимизатором в том, что
а) в ключах нет информации о видимости ключей (нет номеров транзакций)
б) видимость версий определяется только при чтении
Я считаю, что это не бяка. Всё правильно сделано. Так и должно быть.
