I have refreshed the index in question. RDB$STATISTICS now shows 2.9E-7 rather than 4.6E-7 so, if I understand this stuff correctly, that should indicate that it is more selective than it was before. However, the query is still SLOW unless I specifically add the index to the query using the PLAN clause. What else might be causing this?

Here are the statistics for the index in question.

Index BILLING_PRO_KEY (7)
Depth: 3, leaf buckets: 7981, nodes: 4601270
Average data length: 3.00, total dup: 1160727, max dup: 170
Fill distribution:
0 - 19% = 3
20 - 39% = 0
40 - 59% = 4101
60 - 79% = 1137
80 - 99% = 2740

and the primary key, which is being used for the ORDER part of the plan.

Index RDB$PRIMARY17 (0)
Depth: 3, leaf buckets: 7018, nodes: 4601098
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 13
20 - 39% = 0
40 - 59% = 5265
60 - 79% = 1302
80 - 99% = 438