Andrew,

>Yes, possibly too simple for the engine. This may be a case of the
>famous 'brain fade' that the planner succumbs to now and then. Or it
>may be a case of expecting the planner to make a choice that seems
>perfectly logical to us humans, but...
>Anyway, try adding a dummy WHERE clause to your view to force the
>engine to engage available indexes,

I hope your suggestion will help Christian, but I would be greatly
surprised if it did. I've seen the 'brain fade' a couple of times, but
Christian stated that he had tried to use a plan explicitly:

>I tried to feed the following plan to the optimizer:
>PLAN (JOIN(B NATURAL, P INDEX(RDB$PRIMARY16))) but then I get
>an error: "index RDB$PRIMARY16 cannot be used in the specified plan".

This was the same plan as had been automatically generated when working
directly upon a table, and should have worked unless he'd done a
backup/restore or something between running against the table and the view
(due to the names of system generated indexes possibly changing). Since the
optimizer (as far as I know) is only reknown for its black-out intelligence
and not for refusing to obey programmers that can surpass its intelligence,
I think something else must be the problem here.

From the information Christian has supplied, the index should be useful.
The key question now is "Why cannot index RDB$PRIMARY16 be used?"

Set
-confused, but intelligent enough to handle my confusion