Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!in.100proofnews.com!in.100proofnews.com!npeer.de.kpn-eurorings.net!news.cambrium.nl!news.cambrium.nl!news.cambrium.nl!newsfeed.wxs.nl!news-x2.support.nl!newsfeed.pacific.net.au!newsfeeder.syd.optusnet.com.au!news.optusnet.com.au!not-for-mail
From: "Noons" <wizofoz2k@yahoo.com.au.nospam>
Newsgroups: comp.databases.oracle.server
References: <cf90fb89.0312240738.264cc573@posting.google.com> <3722db.0312241421.164d6b23@posting.google.com> <mj8kuvsgb5dbdoklfrj48aiuk69vui5k8j@4ax.com> <3feffd79$0$13349$ed9e5944@reading.news.pipex.net> <3ff03390$0$18692$afc38c87@news.optusnet.com.au> <3ff07919$0$25673$cc9e4d1f@news.dial.pipex.com> <cf90fb89.0312291731.e99c969@posting.google.com> <3FF15551.5420@yahoo.com> <3ff168ae$0$13348$ed9e5944@reading.news.pipex.net> <3ff173ee$0$13348$ed9e5944@reading.news.pipex.net> <3ff1794d$0$13348$ed9e5944@reading.news.pipex.net> <bssk8t$do6$1@news3.tilbu1.nb.home.nl> <3FF275DD.3F0@yahoo.com> <3ff2a667$0$18750$afc38c87@news.optusnet.com.au> <bsua97$rsb$1$8300dec7@news.demon.co.uk> <3ff2e475$1$18694$afc38c87@news.optusnet.com.au> <bsurav$hbs$1$8302bc10@news.demon.co.uk>
Subject: Re: Buffer cache statistics (ratios) and CBO SQL optimization?
Date: Thu, 1 Jan 2004 23:07:05 +1100
Organization: nunovyabizness Pty Ltd
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Lines: 19
Message-ID: <3ff411cf$0$18693$afc38c87@news.optusnet.com.au>
NNTP-Posting-Host: 211.30.91.186
X-Trace: 1072959951  18693 211.30.91.186
Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:251109

Interesting.  Thanks a lot.

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam
"Jonathan Lewis" <jonathan@jlcomp.demon.co.uk> wrote in message news:bsurav$hbs$1$8302bc10@news.demon.co.uk...
>
>
> I think there has been a steady increase in the code
> path, so in my test case, the rate has tended to decrease
> with version of Oracle.  On the other hand, some SQL
> has gone faster because new strategies have been
> introduced to reduce the number of units of action
> required even though the cost of a single unit may
> have increased.
>


