[VLozano]

Antes que nada:
1. FOR ALL ENTRIES:
si vas a usar la cláusula FOR ALL ENTRIES IN, asegúrate primero de que la tabla interna sobre la que se va a filtrar tiene datos. En tu caso, si la primera SELECT no retorna datos, la segunda lee TODOS LOS REGISTROS DE LA TABLA. Y eso duele.

2. SELECT *
No es conveniente utilizar esta sentencia. Es mucho más rápido de escribir, pero a no ser que realmente necesites todos los datos de la tabla, estás metiéndole presión al servidor de datos (y al de aplicaciones).
------------------------------------------------------------------
Y ahora una respuesta (que quizá no te guste)

Alternativas al FOR ALL ENTRIES:
- INNER JOIN
- SELECT SINGLE en un LOOP

La mayoría de desarrolladores "a la antigua" (entre los que me podrías incluir) te dirían que la última es un suicidio. No es cierto. La elección entre las tres posibilidades depende de la cantidad (y reparto entre tablas) de datos a leer, de si se utilizan los índices en las condiciones de selección, y de la carga de memoria que pueda tolerar tu servidor.

Viendo las condiciones de la segunda SELECT, podríamos deducir que el campo que usas para filtrar en el FOR ALL ENTRIES no forma parte de la clave ni empieza un índice. Si es el caso, el INNER JOIN podría llegar a ser contraproducente.

Si las cláusulas WHERE que has dado usan índices, y el rendimiento sigue siendo malo (¿seguro que el cuello de botella está ahí?), quizá deberías usar otra aproximación al problema. Por ejemplo, si realizas un tratamiento masivo en un LOOP posterior sobre la primera tabla, en el que realizas un READ TABLE para coger los datos de la segunda, quizá te interesaría intentar un SELECT-LOOP-SELECT. Mucha gente se llevaría ahora las manos a la cabeza, pero con los nuevos motores de BBDD y el rendimiento del que son capaces los servidores hoy en día, ese gesto está desfasado. Te lo dice un abuelete.