В АСА9.02(25хх) наткнулся на следующую проблему:
имеем таблицу с составным первичным ключом (integer i1,char(32) c2)
T1
type name integeri1char(32)c2other_typeother_data
и таблицу у которой есть внешний ключ к первой таблице, но(!) у нее порядок следования полей в таблице другой, т.е.
T2
type name other_type1other_data1char(32)c2other_type2other_data2integeri1other_type3other_data3
Ясное дело, что FK во второй таблице объявлен как (i1,c2), ведь порядок объявления в таблице не имеет значения!?
Так вот на таких селектах сервер начинает тупить по страшному(я даже и не понял что он в итоге выдает):
select *
from T2 key join T1
Причем иногда в плане может написать что использует FK, но у меня такое ощущение что он пытается подключать таблицу T1 по условию t1.i1=t2.c2 and t1.c2=t2.i1
А вот если сделать
select *
from T2 inner join T1 on T2.i1=T1.i1 and T2.c2=T1.c2
то все нормально работает, и в плане видно что даже использует FK.
Вот такое вот странное поведение.
P.S.: почему такие ключи - не спрашивайте, не важно.

Однако, я это повторить и на 2551 не могу. На рабочих таблицах это видно, при создании же тестовых пустых - нет, все нормально. Буду пытать дальше.

Может быть тут порядок следования полей в таблице и не причем. Суть в том, что на выборке с использованием key join план отличается от того что с inner join. (Хотя, спрашивается почему???!!!)
На рабочей базе:
Запрос1:
select *
from branch_goods key join branch_day_rest
where branch_goods.netcode=384729;

План1:
( Plan [ Total Cost Estimate: 214963.1242 ]
( NestedLoopsJoin[ TRUE ]
( IndexScan branch_goods goods_netcode )
( TableScan branch_day_rest[ ( branch_day_rest.branch_id = branch_goods.branch_id : 3.942547339% Column-Column ) AND ( branch_day_rest.ean_id = branch_goods.ean_id : 100% User ) ] )
)
)

Запрос2:
select *
from branch_goods inner join branch_day_rest on branch_goods.branch_id=branch_day_rest.branch_id and
branch_goods.ean_id=branch_day_rest.ean_id
where branch_goods.netcode=384729;

План2:
( Plan [ Total Cost Estimate: 18.69484355 ]
( NestedLoopsJoin[ TRUE ]
( IndexScan branch_goods goods_netcode )
( IndexScan branch_day_rest branch_goods_fk )
)
)
Возможно, это просто заблуждения оптимизатора, и внешние ключи тут ни причем. Но из-за того, что в документации написано, что "используйте по возможности key join" у меня всплыла такая вот проблема, теперь пишу все через иннеры. Когда эта база была на АСА6, там все было нормально.
P.S.:branch_goods - 3,5 млн, branch_day_rest - 86 млн

Или вот еще так
Запрос3:
select *
from branch_goods key join branch_day_rest FORCE INDEX(branch_goods_fk) where branch_goods.netcode=384729;

План3:
( Plan [ Total Cost Estimate: 1491236.779 ]
( NestedLoopsJoin[ TRUE ]
( IndexScan branch_goods goods_netcode )
( IndexScan branch_day_rest branch_goods_fk )
)
)

Странноватенько. Не смотря на то, что он понял подсказку про индекс, cost все равно какой-то не из этой жизни...

М-да, вот так всегда.
ebf 3044 спас.
Хотя сам всем говорю, что надо ставить последние ebf, а сам даже не проверил на 3044.
на первый запрос вот такой план стал:
( Plan [ Total Cost Estimate: 13.04366771 ]
( NestedLoopsJoin[ TRUE ]
( IndexScan branch_goods goods_netcode )
( IndexScan branch_day_rest branch_goods_fk )
)
)
Т.е. все ОК.
P.S.: Глюк всплыл сразу после перехода с 6.04 на 9.01, патчил регулярно, ожидая что вдруг исправили, я уж было подумал что и не исправят его. Ан нет...)