Re: SQL Tuning
Date: Sun, 6 Jul 2003 14:30:35 +0100
Message-ID: <3f0823ff$0$18496$cc9e4d1f_at_news.dial.pipex.com>
<- (-)> wrote in message news:3f06e73a.248344370_at_newzilla.xs4all.nl...
> On Mon, 30 Jun 2003 13:22:41 -0700, Daniel Morgan
> <damorgan_at_exxesolutions.com> wrote:
>
> >> Yes, thank you for your reply but now it almost becomes as difficult
> >> as making the CBO jumping hoops. :>. This will be my next of questions
> >> for anybody who responds.
> >
> >Glad to help but I don't understand your question about the CBO.
>
> I was just saying that making the CBO do what your want is very
> difficult. Sometimes the CBO seems to have a mind of it's own but not
> a very smart one. Also sometimes thing just become too compilate
> because you have to take too much factors into consideration to be
> cost effective. The quest for inteligent life in the CBO is one of
> those things I like to avoid because I think it would not be cost
> effective as it would take a lot of time.
I confess that I cannot understand this attitude. You seem to be saying that you'd like to ignore new features, force somewhat arcane syntax on developers, make sql behave in the same way regardless of whether the driving dataset has 2 rows or 2 billion. all this because the CBO is going to take 'a lot of time' to understand. And presumably abandon relational databases altogether when 9i is desupported as there won't be a single RDBMS on the market with simple rules to follow regardless of the datasets involved by then.
-- Niall Litchfield Oracle DBA Audit Commission UK ***************************************** Please include version and platform and SQL where applicable It makes life easier and increases the likelihood of a good answer ******************************************Received on Sun Jul 06 2003 - 15:30:35 CEST