Re: separate data/inidex

I agree. I thought he was saying that most of the time we do full table scans, etc. And given that many of my application tables have been in the multi-gigabyte range that would be a complete non-starter.

When one is looking for a single part of a Boeing 747 ... one does not want to scan every part for every plane ever made.

Daniel Morgan

Jonathan Lewis wrote:

> Comments in-line
>
> --
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> Author of:
> Practical Oracle 8i: Building Efficient Databases
>
> Next Seminar - Australia - July/August
> http://www.jlcomp.demon.co.uk/seminar.html
>
> Host to The Co-Operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
> Daniel A. Morgan wrote in message <3CC2CB08.64C747AF_at_exesolutions.com>...
> >Please help me here with two things.
> >
> >1. "Nowadays to satisfy queries, you're full scanning tables, full scanning
> indexes,
> >not using indexes at all,...."
> >
>
> It is very easy to misunderstand the intent of a comment
> on the newsgroup, but I think if you re-read Connor's post
> carefully you will appreciate that he is not saying "you must
> full scan tables"; he is simply listing a number of the mechanism
> that are commonly (and necessarily) activated in a modern system.
>
> >Since when? I work very hard to not do these things.
> >
>
> Don't work too hard at it. Sometimes the biggest
> performance problems are introduced by trying
> to push Oracle too hard into paths which use
> index range scans and index unique scans to
> access tables by rowid; resulting in excessive
> CPU usage and CBC latch contention.
Received on Mon Apr 22 2002 - 11:15:03 CDT