Diego,
FB uses all available index for searching but may not report it in
PLAN text(developers says it fixed in FB2).
FB will use date index and MSISDN index and level index to reach
match rows.
you have got too much rows for this count operation.
so, you should reduce table and index scaning.
FB will does table scanning in subquery for each selected row.
it kills FB, espacially in multiuser environment kills the server.

in my query there is only one pass. gruping and counting doesn't
interested with table. i think there is no faster alternative for a
MGA engine.

Regards.

Ali

--- In firebird-support@yahoogroups.com, "zimrilin2000"
<drodriguez@a...> wrote:

> Sorry, this is the query PLAN
>
> PLAN (OC2 INDEX (IDX_OPPORTUNITY_CALLS))
> PLAN (OC INDEX (IDX_OPPORTUNITY_CALLS))
>
> Still the same query PLAN if I add 2=0 (it is already using the

index)

>
> The table has 5279698 rows and 1937943 distinct MSISDN
>
> Diego