More research into this problem is yielding some interesting results. I took the table in question, exported it from my customer's database and imported it into both a 1.5.5 and a 2.0.5 database on my server.

The 1.5.5 version on my server behaves in exactly the same way as my customer's server. The same PLAN is reported by both servers, namely:

PLAN (BILLING_IMG_TABLE ORDER RDB$PRIMARY17)

Using this plan the query is SLLOOWW!

The 2.0.5 version reports a different plan:

PLAN (BILLING_IMG_TABLE ORDER RDB$PRIMARY17 INDEX (BILLING_PRO_KEY))

Which I understand to be equivalent to the 1.5.5 plan. Even though the PLAN looks to be more like what I would expect, the query is still slow unless I manually specify the PLAN or do something else to cause the ORDER part of the plan to be replaced by SORT. This plan executes almost instantly:

PLAN SORT (BILLING_IMG_TABLE INDEX (BILLING_PRO_KEY))

This is now leading me to believe that it isn't that FB is ignoring the BILLING_PRO_KEY index but rather that using the primary key to order the result set that is causing the problem.

Checking the I/O statistics shows that the PLAN selected by FB requires something in the order of 7K buffer reads, whereas the manually entered PLAN requires only about 8 buffer reads.

Given that the query only returns a single record, how can the FB selected plan be so much more inefficient. There is no way it should require that many I/Os to order a single record.

There are 4.6 million rows in the table.

Is this a bug in the optimizer?