Введение.
Имеется таблица
ID_OBJ1 integer , // Идентификатор из табл. tb_tree1 древовидная структура
ID_OBJ2 integer , // Идентификатор из табл. tb_tree2 тоже древовидная структура
OPER_DATE DATE // Дата совершения операции
...остальные поля не существенны, но double precision

Первичный ключ (ID_OBJ1, ID_OBJ2, OPER_DATE) и соответственно, автоматически созданный индекс rdb$primary15 уникальный и по возрастанию

Диапазон дат OPER_DATE около пяти лет.
Количество строк около 80`000. т.е. все уникальные т.к. есть первичный ключ (
практически каждый день по несколько записей разными id_obj1 и id_obj2).

Далее есть рекурсивная хранимая процедура для обработки этой таблицы.
Процедура выполняет необходимые действия около 30 секунд на IB5, IB6 и FB.
А вот на IB6.5 около 10 минут!?
Основная потеря времени происходит из-за 2-х запросов в теле процедуры.

SELECT MAX(OPER_DATE)
...
WHERE (ID_OBJ1 = :ID_OBJ1) AND (ID_OBJ2 = :ID_OBJ2) AND (OPER_DATE BETWEEN :ST_DATE AND :EN_DATE)

SELECT MAX(OPER_DATE)
...
WHERE (ID_OBJ1 = :ID_OBJ1) AND (ID_OBJ2 = :ID_OBJ2) AND (OPER_DATE < :OPER_DATE)

В силу того, что сначала select выибирает около 800 записей удовлетворяющих WHERE, затем MAX выбирает единственное значение.
Т.к. процедура рекурсивная, то это выполняется многократно с разными комбинациями id_obj1 и id_obj2.
Учитывая тот факт, что у заказчика техника слабая, то для IB5, IB6 и FB можно было дальше и не напрягать мозги по увеличению скорости процедуры. Но я придурошный и сам себе поставил ограничение - если заказчику приходиться ждать больше 7 секунд, то это чудовищно долго, а я где-то не додумал, не дотянул, схалтурил.

Теперь суть (на IB6.5.0.28)
Удалил первичный ключ и соответственно индекс rdb$primary15.
Пробовал всяко-разно строить уникальные индексы по этим трём полям:
- менял порядок следования столбцов в индексе;
- строил индексы как по возрастанию, так и по убыванию.
Оказалось, если строить по убыванию, а OPER_DATE на первом месте, то работает быстрее - это и понятно т.к. работает функция MAX. SELECT в этих случаях обрабатывает уже не 800 записей, а одну две. Но к заметному увеличению скорости в целом это не привело.

А теперь тот самый аут
Построил индекс (ID_OBJ1, ID_OBJ2, OPER_DATE) уникальный по возрастанию. По смыслу это тот-же самый индекс rdb$primary15, но построенный по моей команде принудительно, а не автоматичеки после создания первичного ключа.

Вся процедура целиком сработала за ОДНУ СЕКУНДУ !? !? !?

Повторил снова всякие разные индексы. Произошло тоже самое.
Т.е. прослеживается некая закономерность.

Кто-нибудь может что-то прокоментировать?

На момент каждого теста в таблице существовал только один единственный индекс, но каждый раз разный. Вот только он и использовался. О чём собственно и сообщал IBExpert. Если бы что-то было по другому - я бы сразу сообщил.

Я вообще-то в курсе, что по убыванию. И тестировал. Об этом написал.
Ну суть темы в том, что наилучшим оказался индекс по возрастанию аналогичный индексу первичного ключа.
Ранее я считал их тождественными, а теперь нет!