> >> I think I could me clearer. The views could be partially
> >> prepared/compiled(at creation time), excluding the optimizer
> >> processing. And, when the view is to be used, the optimizer would be
> >> called to evaluate the plan to be used.
> >>
> >> It's just my 2 cents.
>
> > We disagree there then :-)
>
> We might be in agreement. See further.

Even better... Although it doesn't raise new ideas ;-)

> > The plan used to execute a query can be very different from the plan
> > used for only the view itself.
>
> I agree. I may have explained too simply. The plan would be recreated
> everytime the view is referenced. What I meant by partially prepared,
> was simply the BLR for the view "without" the plan.

See the post by Ann. The plan of the view isn't persistent. The BRL is
and when executing something that includes the view, any WHERE clause
or whatever will be mixed with the view BLR. From there, any record
streams etc are all merged like it's just one big statement.

> > Given that a view can be used in conjunction with a very complex
> > additional query, I think that the plan should be recreated every time
> > the view would be accessed.
>
> Totally agree.
>
> > Of course, a "query plan cache" could be useful for all queries in

Firebird

> > :-)
>
> This surely could be useful, since most of the time the same queries
> will be used by the same application on the same database. But, there
> will have to be a mechanism to update that cache, and have the ability
> to remove some cached plans.

Of course. The engine could/should keep track of useful statements to
cache and totally useless ones...

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com