Hello, Alexey!
Alexey Popov wrote:
Это понятно. У меня вызывает вопросы выбор между планами
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.
на основании чего сделан вывод, что оптимизатор "должен принимать
решение в процессе"? На этапе prepare известна кардинальность
таблиц и селективность индексов, и во время выполнения она не
меняется, да и скорректировать эти измерения никак.
Ведь в принципе нетрудно одновременно с построением битовой маски
посчитать количество записей, которые попало в неё.
блин. это не количество записей. Это потенциальное количество
записей без учета версий. Даже если запись попала в битмап,
она может быть удалена. Или, у одной записи могут быть тыщи
версий, из которых или все или ни одной видны конкретной
транзакции, выполняющей запрос.
Видимость версий определяется только в момент чтения версий.
p.s. я фигею, дорогая редакция. у нас (в ФБ) основная
"бяка" с оптимизатором в том, что
а) в ключах нет информации о видимости ключей (нет номеров транзакций)
б) видимость версий определяется только при чтении
уже, как бы, плешь проели версионностью. И она не может не влиять
на оптимизатор.
Тупой пример - запрос с where field = 1, было 100к версий с
field = 1, но в очередной транзакции был update field = 2.
Стало записей (версий) = *2, ключей = *2, snapshot до update
видит одно, транзакция с update видит другое. 2x ключей указывают на
100к записей, где на самом деле 200к версий. Оптимизатору-то что
делать?
Решите проблему - вручим нобелевскую.
Собственно, про номера транзакций в ключах недавно был
здоровенный топик на sql.ru.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
