Re: RULES vs. COST
Date: Thu, 09 Feb 95 22:12:44 GMT
Message-ID: <3hdi7b$obc_at_pheidippides.axion.bt.co.uk>
dischner_at_med.uni-muenchen.de (Anton Dischner) wrote:
>In article <3havdo$91b_at_ams.amsinc.com>, Edward_Hillman_at_mail.amsinc.com (Ed
>Hillmann) wrote:
>
>> Hi folks. I'm trying to gather opinions and guesses about Oracle7's
>> optimization
>> options, and what currently is the best setup.
>>
>> My understanding is this: Oracle has always used a RULES-based system.
>> Oracle7 now has both a COST-based as well as RULES-based system.
>Correct
>> These are what I have heard...and please feel free to shoot holes in them if
>> they're not right:
>>
>> - RULES-based optimization will not be supported by Oracle in the next few
>> years.
>Yes, Oracle's written statement.
>> - The current COST-based system is not working 100%, ie. the optimal execution
>> plan is not always chosen,
>Yes, this is correct
our experiance is that COST does not work at all - were waiting for 7.1 with interest.
>> - When the RULES-based system is no longer supported by Oracle, they will
>> have made modifications to the COST-based system, so that the parser will
>> choose the correct path, no matter how the query was originally optimized.
>I hope so, i don't believe it!
>I think we will have to hassle around with compiler hints (doing optimization
>on our own :-().
>>
>> I was wondering if anyone had any opinions on which is currently the best
>> setup (RULES vs. COST), based on any experience. I keep hearing adament
>> defenses of both systems, so I figure the more the merrier. :)
RULES is what our Guru sugests
.
|Maurice Walshe You'll Never Get to heaven with an Ak47, | | But a Zu23's good for low flying Cherubim | |Software Engineer | |c=gb/admd=bt/o=hti(highly technical individuals)/pn=maurice walshe | |c=gb/admd=gold 400/o=mhs/pn=maurice walshe | |c=gb/admd=gold 400/o=btt/pn=maurice walshe | |mjwalshe_at_tymnet.bt.co.uk | |FAX C=gb/admd=gold 400/X.121=9441442237124 | |TLX C=gb/admd=gold 400/X.121=8519312111392 | |Phone= + 44 142237140 | |-----------------------------------------------------------------------------Received on Thu Feb 09 1995 - 23:12:44 CET