Re: Unexpected Tkprof Row Count

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Sun, 29 Aug 2004 09:02:08 +0000 (UTC)
Message-ID: <cgs62g$rpu$1@sparta.btinternet.com>

Your output is headed 'Execution Plan'. This means it was generated by tkprof running an 'explain plan'. So the reported plan is not necessarily what happened at run time. Which means the statistics from the trace file can be lined up with the wrong access lines.

This used to be a clue in early versions of Oracle that the tkprof output was lying - but in your version, you should have both the 'Execution Plan' lines (second set) and the 'Row source statistics' lines (first set). Do you have an example where the 'Row source statistics' show the same anomaly ?

-- 
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated July 27th




"Matt" <mccmx_at_hotmail.com> wrote in message
news:cfee5bcf.0408270015.8ef24b2_at_posting.google.com...


> Oracle 8.1.7.2.1 EE on HP-UX 11

>

> Does anyone know of a reason why a SORT (GROUP BY) row source

> operation would increase the number of rows returned from a query...

>

> I thought that a GROUP BY would reduce the number of rows, not

> increase them...

>

> Here is the TKPROF output which shows that a JOIN between 2 tables

> ('PS_TM_PEFF_GPQCAL' and 'PS_TM_PEFF_BNCHMRK') returns about 110,000

> rows but when this is passed up to the GROUP BY operation, the row

> count jumps up to 7.3 million.

>

> Rows     Execution Plan

> -------  ---------------------------------------------------

>       0  SELECT STATEMENT   GOAL: CHOOSE

>      61   SORT (ORDER BY)

>      61    VIEW

Received on Sun Aug 29 2004 - 04:02:08 CDT