RE: Tim Gorman's "...Cost-Based Optimizer.doc"

Ahh, pre-fetching, I forgot about that... BUT still doesn't your point about highjacked read heads also hold true for prefetching?

Wouldn't some other user request highjack the read head in a pre-fetching scenario? It seems to me the highjacked scenario could fit all types of read requests...To clarify, any single read request could be interleaved among all the other read requests, no?=20

Also, some context would be appropriate, I think. We jumped from talking about disks (I was envisioning non-SAN) to disk reads in a SAN environment. I apologize, If I'm mistaken since I haven't read the article in question yet.

Thanks!=20
-----Original Message-----
From: Wolfgang Breitling [mailto:breitliw_at_centrexcc.com]=20 Sent: Thursday, June 16, 2005 10:52 AM
To: Khemmanivanh, Somckit
Cc: cmarquez_at_collegeboard.org; mgogala_at_allegientsystems.com; oracle-l_at_freelists.org
Subject: Re: Tim Gorman's "...Cost-Based Optimizer.doc"

My take on that is that in a real multi-user system, the chance that "the next block of data to be read is "actually" adjacent to the last=20 block read" is virtually nil. By the time your session issues the next=20 scattered read, someone else will have "kidnapped" the read head and=20 left it somewhere else on the disk.
I believe that if scattered, i.e. multi-block, reads are faster than=20 sequential, i.e. single-block, reads it is because the SAN recognized a=20 read pattern and prefetched the next bunch of block into the cache.

Khemmanivanh, Somckit wrote:

> Could it be that scattered reads take less time "if" the next block of
> data to be read is "actually" adjacent to the last block read,
therefore
> you wouldn't be incurring seek time as you might with sequential
reads?=3D20
>=20
>=20
--=20
Regards

Wolfgang Breitling
Centrex Consulting Corporation
www.centrexcc.com

--
http://www.freelists.org/webpage/oracle-l