Re: SELECT statement efficiency question

On Apr 9, 11:36 am, Mladen Gogala <mgogala.SPAM-ME...._at_verizon.net> wrote:
> On Mon, 09 Apr 2007 08:08:53 -0700, hpuxrac wrote:
> > Does this mean that you have disproven and are now disavowing your
> > statements made earlier in this thread?
>
> No, it means that you don't know how to read and are, therefore,
> functionally illiterate.
>
> --http://www.mladen-gogala.com

You wrote this earlier in this thread talking about defining additional indexes ...

... Charles, this is the line I frequently find in many books, CBT and
manuals and yet I have never seen insert or delete slowed down to the unacceptable levels because of too many indexes. The only method to diagnose that this is indeed happening would be to observe significant
increase in average I/O time on the underlying data file. Again, I've never even seen this happening. I believe that this thing with too many indexes is dangerous only in the extreme situations and it
is very hard to diagnose because the process that waits for writing the
index blocks is DBWR so the users never wait for the blocks to be written. Users may wait for checkpoints or log file sync but not for the
index

Mladen what you wrote just doesn't make sense. Any time you add indexes to any table you affect to some degree the scalability of an application. Tom Kyte's test harness is an easy way to look at the impact of adding indexes. A 10046 trace is another way.

Charles questioned what you wrote and put in a simple test. You appeared to confirm the results noted by Charles yourself in a later post. Received on Mon Apr 09 2007 - 11:40:57 CDT