Re: *Measuring sql performance (elapsed time and scalability) by number of logical reads

Hi,

It's hard to add even a couple of cents to what Wolfgang said, so I'll and just add a couple of "kopejka" which is russian centi-rouble ;-)

1. 168826 rows were taken as an input to hash join, which means 168826 calls to hashing function. That is IMHO where the CPU had mostly been consumed. Look, there are almost two orders of magnitude difference.
2. Things might change a lot, if you'll try the same test on a busy instance, where other sessions will contend for the CBC latches, some of which will be responsible for an access to your blocks

HTH
- Andrey

> I'm trying to undestand why I have:
>
> 1. Fetch 2 0.26 0.25 0 1725 0 1
> 2. Fetch 2 0.06 0.05 0 7559 0 1

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