RE: Tim Gorman's "...Cost-Based Optimizer.doc"
- From: "Khemmanivanh, Somckit" <somckit.khemmanivanh@xxxxxxxxxxxxxxxx>
- To: "Wolfgang Breitling" <breitliw@xxxxxxxxxxxxx>
- Date: Thu, 16 Jun 2005 11:11:12 -0700
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@xxxxxxxxxxxxx]=20
Sent: Thursday, June 16, 2005 10:52 AM
To: Khemmanivanh, Somckit
Cc: cmarquez@xxxxxxxxxxxxxxxx; mgogala@xxxxxxxxxxxxxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
