Hello, WildSery!
WildSery wrote:
Это называется индексное покрытие - когда все необходимые в запросе
поля есть в индексе. В FB такая техника, увы, невозможна, ибо всё равно
нужно посетить запись для определения её видимости для читающей тр-ции
А в будущем планируется что-нибудь в эту сторону?
Вроде бы Анна посмотрела что с этим можно сделать, но пришла к выводу
что
сильно повысится оверхед ключа, т.к. там придется хранить информацию
о номере транзакции ключа. Разумеется, вырастет размер индекса, из-за
того, что к каждой ссылке на запись будет приклеен номер транзакции,
а это дело будет плохо упаковываться.
ну и чего-то там еще затормозится, причем не одно.
Для сравнения могу привести идею хранить в файле сортировки не все
выбираемые запросом столбцы, а только столбец сортировки и ссылку на
запись. Как результат это получится идентично ORDER BY INDEX,
только типа "индекс, создаваемый на ходу", а такие вещи сейчас сервер
при большом числе записей делает медленно (медленнее чем нынешний PLAN
SORT), по понятным причинам (см. dataacesspaths.htm).
Так что идеи это хорошо, но на поверку не все они приводят к желаемому
ускорению.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
