Неоптимальный план на очевидном запросе

[WildSery]

У меня живьём FB 1.0.3 и на тестовом стенде FB 2 RC3 (не ругайте, так сложилось, завтра поставлю RC4, уточню и там). Проверил на обоих.
Читал Release Notes, ничего такого не встретил, возможно, "особенность" и там присутствует.

Код: Выделить всё

CREATE TABLE LIN (
    EID       INTEGER NOT NULL,
    EIDDOC    INTEGER DEFAULT 0,
    EID1      INTEGER DEFAULT 0,
    ...
);
ALTER TABLE LIN ADD CONSTRAINT PK_LIN PRIMARY KEY (EID);
CREATE INDEX LIDDOC01 ON LIN (EIDDOC);

Селективность PK_LIN 0.0000001508...
Селективность LIDDOC01 0.0000019343... (всего на порядок меньше)

Код: Выделить всё

select min(eid) from lin where eiddoc=:param1
PLAN (LIN ORDER PK_LIN)

Почему-то хочет ползти по PK, ищя самый маленький, что было бы логично, если не смотреть на статистику для LIDDOC01. Выполняется 1.5 секунд в IBExpert против 15ms для "подруленного" хинтом

Код: Выделить всё

select min(eid+0) from lin where eiddoc=:param1
PLAN (LIN INDEX (LIDDOC01))

[kdv]

Почему-то хочет ползти по PK, ищя самый маленький, что было бы логично, если не смотреть на статистику для LIDDOC01. Выполняется 1.5 секунд в IBExpert против 15ms для "подруленного" хинтом

индекс по ПК имеет почти безусловный приоритет.
Хотя на мой взгляд тут order в плане не в кассу.
Причем, насколько я помню, индекс LIDDOC01 используется и для "автоматического" плана, просто оно не умеет это в плане показывать. хотя могу и наврать, давно по оптимизаторам не лазил.

[dimitr]

давняя известная грабля. Пока не исправлялась.

[WildSery]

Вообще, по зрелому размышлению, никакой это не баг. И без анализа статистики индекса ничего тут оптимизатор не сделает.
Это у меня достаточно равномерное распределение, а вот если там разброд будет, то 1 запись по параметру, то 10000.... Тогда ORDER PK имеет право на жизнь.

2kdv:
То, что он PK, кстати, совсем не при чём. Я построил дополнительный desc по тому же полю и изменил с min на max - он его взял, тоже plan order. Так что всё дело только в избирательности.