Hello !!!

Well, as you are saying, Plans is the bad mechanism to fix the optimizer
problems, i�m agree. But right know the optimizer still have holes. Many
times we (interbase users or databases adminitrator) have needed "select"
some records with a condition (optimizer go crazy) inside triggers to take a
action to do, thinking in a big table, how i can improve the "select"
perfomance?. Today, plans inside SP code and index is a solution (for me) to
improve the database performance (i�m not abusing with plans and index).

In the other hand, if the optimizer will become logic and operative, still i
would like some times force it for the optimization query.

Best Regards
Danny

"Jim Starkey" <jas@...> escribi� en el mensaje
news:3.0.5.32.20020521112437.00a36a60@......

> At 11:13 AM 5/21/02 -0400, Ann W. Harrison wrote:
> >
> >Yes, it's a conceptual problem - the person who added plans ran into
> >a problem with triggers and just stopped rather than finding and fixing
> >whatever it was that didn't work. At the moment, fixing that bug isn't
> >at the top of the list...
> >
> >
>
> <rant type=habitual>
>
> The bug isn't that triggers can't have plans but that plans are
> necessary at all. Plans exist for exactly one reason: The
> optimizer is broken. If the optimizer worked, there would be
> no reason for the inconceivably ughly plan mechanism.
>
> Databases should know more about their internals than their users.
> If they don't, the solution is to make the database smarter, not
> teach optimization to users.
>
> </rant>
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>