We have a strange scenario at one of our sites where one query slows down dramatically after we call SET INDEX STATISTICS.
Unfortunately this is used a lot so it causing performance issues throughout the system.

The basic query is:

SELECT DISTINCT BR.BASE_SN, R.TITLE
FROM RES R
JOIN BASERES BR ON BR.BASE_SN = R.BASE_SN
WHERE R.STATUS=1 AND BR.STATUS=1 AND
BR.BASE_SN IN (<insert list of primary keys>)

Both the BASERES and RES tables have about 25000 records. There is a FK constraint R.BASE_SN -> BR.BASE_SN and BR.BASE_SN is the primary key of the BASERES table.
The status columns are not indexed as there are only 2 distinct values. However, I did try adding an index to see if that makes any difference and it doesn't.

For all our other sites this is not a problem and this site runs ok after exporting and importing the data. Then, if we update the index statistics then the performance drops.
For them, the query take 90secs but after export/import, the query takes about 6secs. This returns just 334 records.

If we change the WHERE to R.BASE_SN IN (<insert list of primary keys>) then the query is again fast. Unfortunately, for all other DBs tested from other sites,
the performance is worse when we change the alias.

Using the clients database, it is easy to replicate.

1. Load IBExpert and run query (fast)
2. Recalculate index statistics in IBExpert
3. Run query again - now slow.

Basically fbserver gets locked at 100% CPU and noone else can use the database.
This is using FB SS 1.5.5 on Windows and Linux.

Any thoughts as how we can resolve this issue?

Thanks.