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

> 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 ;-)

Zdrastvuj Andrey :)

> 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

I test was on a busy system,
I think the latch wait would be reported in the trace file (10046, 12) ...

Regards,
Dimitr

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