RE: PARALLEL QUERY

  • From: jonathan@xxxxxxxxxxxxxxxxxx
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Wed, 17 Oct 2007 18:50:53 +0100

Hints are not suggestions - they direct the optimizer through 
(or away from) a specific code path, or direct it to adjust 
some of the arithmetic.

The problem with hints is that they are badly documented, hardly
anyone really knows what they mean, and nobody has any idea about
what special case code might exist that affects the way that a 
hint is followed.

In this case we have very little to go on: the OP does not tell
us what the query was selecting, nor the execution path that was
actually taken. However:

To the best of my knowledge the /*+ parallel(alias, degree) */ hint
does NOT tell the optimizer to use parallel execution, it merely tells
the optimizer to divide the cost of a tablescan on 'alias' by 'degree'
(allowing for the effect of the _optimizer_percent_parallel in general
and a fixed 0.9 scaling factor in 10g specifically) and then follow the
consequences.

It is perfectly feasible that the optimizer found a serial index access
path that was cheaper than the 'tablescan cost / 4' dictated by the hint.


Regards
Jonathan Lewis



> Subject: RE: PARALLEL QUERY
> Date: Tue, 16 Oct 2007 06:58:36 -0500
> From: "Herring Dave - dherri" <Dave.Herring@xxxxxxxxxx>
> 
> Deepak,
> 
> More than likely the optimizer determined that a parallel query with just 4 
> PX slaves is not more beneficial than a serial scan, whereas 16 slaves is 
> more beneficial.  I've never seen this before, but then again our databases 
> are configured to maximize parallel performance, so any parameter related to 
> parallelism is set to a larger than average value.  
> 
> To validate what the optimizer is doing, set event 10053 for each query and 
> review the optimizer's decisions.
> 
> Also, remember that hints are just that, a hint or suggestion, not a "force".
> 
> Dave


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


Other related posts: