>
> No. IMHO, the optimizer is doing a good job. It uses indexes with a good
> selectivity and first horizontally filter table A by using A_IDX1 and
> uses that already filtered "stream" to join table B via index B_IDX1.
>
> Just for the records: Firebird can join two indexes on the same table
> via a bitmap vector (as shown in the execution plan before re-computing
> index statistics), but in your case, the optimizer uses a different
> path, which executes the query pretty fast.

i begin to understand why i obtain this plan and why it's normal. I decomposed my inner join request in two "for select" request and i obtain the same number of read and nearly the same execution time.
After some search i see that some other database merge index to use several index on same table but this method is cost time effective and in some case it's preferable to do much read that use several index.

but i need your help to have a better understand of how works the optimizer with indexes (maybe a document exists ?) because i think i have put to much indexes that don't serve in my database.