Оптимизатор в Firebird 2.1

Прошло одно изменение без особого внимания, но оно может очень влиять на производительность при переходе со старых версий. В композитных индексах теперь считается селективность для каждого сегмента отдельно, что по логике правильнее, но в редких случая может менять порядок таблиц в соединении кардинально:

Selectivity Maintenance per Segment
D. Yemanov, A. Brinkman
Index selectivities are now stored on a per-segment basis. This means that, for a compound index on columns
(A, B, C), three selectivity values will be calculated, reflecting a full index match as well as all partial matches.
That is to say, the selectivity of the multi-segment index involves those of segment A alone (as it would be if it
were a single-segment index), segments A and B combined (as it would be if it were a double-segment index)
and the full three-segment match (A, B, C), i.e., all the ways a compound index can be used.
This opens more opportunities to the optimizer for clever access path decisions in cases involving partial index
matches.
The per-segment selectivity values are stored in the column RDB$STATISTICS of table RDB
$INDEX_SEGMENTS. The column of the same name in RDB$INDICES is kept for compatibility and still
represents the total index selectivity, that is used for a full index match.

и если была таблица documents(...doc_state int, doc_date ... ) c индексом по (doc_state, doc_date), то теперь, при условиях по doc_state, будет браться селективность не всего композита(а она могла из-за даты быть достаточно неплохой), а только поля doc_state.