> STATISTICS INDEX index_name, so we know for sure the optimizer makes
> decisions on the right information.
> Could you also post the PLAN?

I already did that. Plan is:
PLAN SORT (JOIN (A NATURAL,MM INDEX (RDB$FOREIGN23),M INDEX
(RDB$PRIMARY5),S INDEX (RDB$FOREIGN14),E INDEX (RDB$FOREIGN15),AG
INDEX (RDB$FOREIGN17),R INDEX (IDX_RES_ATHID_AGE_TIME),C INDEX
(RDB$PRIMARY3)))

> Ooops i forgot the sub-select :

Now it works. Plan is:
PLAN (R2 INDEX (IDX_RES_ATHID_AGE_TIME))
PLAN SORT (JOIN (A NATURAL,MM INDEX (RDB$FOREIGN23),M INDEX
(RDB$PRIMARY5),S INDEX (RDB$FOREIGN14),E INDEX (RDB$FOREIGN15),AG
INDEX (RDB$FOREIGN17),R INDEX (IDX_RES_ATHID_AGE_TIME),C INDEX
(RDB$PRIMARY3)))

But the result isn't better. I think, grouping by STARTDATE, NATION
and CITY cannot work since most of the results come from different
meets (-> cities). I removed these, but I left subselect for
T_RESULTID. But because of column grouping still doesn't help.
Without that column it works, but I can't get the city for a specific
result.

> It will speed-up, but if it really helps that much i don't darve to
> How many records should be choosen from the result table with a
> specific T_STYLEID ?

I have about 25 different values for T_STYLEID. Then most of the time
I set a filter on A.GENDER (two values) and T_SESSION.COURSE (two
values).

Maybe I should add the tables RANKING and RANKINGITEM with
precalculated result of the most common queries I need and
RANKINGID,SORTNUMBER,T_RESULTID as columns in RANKINGITEM.

cu Christian