Re: SQL Tuning

From: Niall Litchfield <niall.litchfield_at_dial.pipex.com>
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

Original text of this message