Re: long runtimes cured by cutting hash_area_size by 90% - ???

I have a hard time believing that there is no plan difference. Can you post the tkprof output from the two runs. Make sure to run them to separate trace files or use tkprof with aggregate=no to keep the output of the two sql separate.

At 08:43 PM 4/7/2003 -0800, you wrote:
>Hash_Area_Size runtime
>10,000,000 6:16 ( 6+ mins )
> 1,000,000 0:15 ( 16 secs)
>
>Why?
>Isn't bigger always better for hash_area_size?
>Is another param affected?
>
>That's the only param that changed, via alter session.
>
>Oracle 8.1.7, Sun/Solaris, 8 cpus, lots & lots of memory,
>no other queries, or 3 concurrent: same runtime.
>
>The query joins 9 tables, one has 1.8M rows, the others under 60k rows.
>
>Explain Plan shows 5 nested loops, 3 hash joins, and no diff between plans
>with the 2 values.
>
>Chris Barr

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Wolfgang Breitling
  INET: breitliw_at_centrexcc.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).