Firebird has cost-based optimizer, it means that plan for (some) queries
is chosen on the basis of table cardinality and index(es) selectivity.

* Index selectivity is property of each index, and is not recomputed
automatically during updating of data, instead, it is recomputed
either by executing SET STATISTICS INDEX command,
or after creating or activating index (i.e. also during db restore).

* Table cardinality is not computed as "real" value, but only estimation
based on number of allocated data pages. It means that after
making lot of changes into data and doing backup/restore,
data in restored database will be stored more "dense",
and optimizer will use different cardinality estimation.

Because you have no control over these factors, you should try
to rewrite your queries to run fast on restored database too.

Btw. are the indexes active in the restored database ? :-)

Ivan
http://www.volny.cz/iprenosil/interbase/

>From: "Alexander Tabakov"
> I have two identical installations of Firebird 1.0.3 running on Win2K
> Server boxes. Both clients and servers use one and the same gds32.dll(ver. 6.2.3.972)
> which comes with FB 1.0.3.
>
> One of the boxes is in production environment and the other is my test
> box. I backup the production database and restore it locally for tests. The
> problem is that I receive two different query execution plans on one
> and the same query. No data was modified.
>
> On my test box (fortunatelly) I get a full table scan for a table with
> 150K records so it executes for 13sec while on the production database
> an index is used and the same result executes for 90ms!!!
>
> Indexing is one and the same on both databases.