Hmm, limited information, but I'll tear your plan apart and comment
within:

> PLAN JOIN (VIEW_GRAAFIKU_VAHETUS TAB_TOOLEPING INDEX
> (RDB$PRIMARY15),

That's a great start.

> VIEW_GRAAFIKU_VAHETUS TAB_GRAAFIK INDEX
> (FK_TLEPING_G,CU_GRAAFIK_KUUPLEPVAH),

Hmm, this could be OK, depending on the selectivity of the two indexes.

> VIEW_GRAAFIKU_VAHETUS TAB_VAHETUS
> INDEX (RDB$PRIMARY4,FK_VLIIK,FK_VLIIK,FK_VLIIK))

Hmm, this seems bad. Why use FK_VLIIK thrice when you already are
using hte primary key? Add some +0 or ||'' to the fields to get rid of
these foreign keys.

> (TAB_TYYPGRAAFIK INDEX (RDB$PRIMARY30))

Brilliant

> (TAB_TYYPGRPAEV INDEX (FK_TYYPGR))

Maybe OK, depending on selectivity.

That's about as much as I can help you given the information you
provided. I don't think it is slow prepare that is the cause of your
problem (I've hardly heard about that being a problem with Firebird
before - except for a few persons looping through a set repreparing
for every execution), just that it takes a long time for Firebird to
find the first record (are you by any chance using ORDER BY?).

Set