Re: interpreting statspack reports ( PX Deq )

Jonathan, et al-

Just to clarify and reiterate my comments: with respect to the server the PQ events can indeed be regarded as idle events. That is, tuning the instance will do nothing for PQ performance. And yes, it may be symptomatic of a bad pq plan, but must be dealt with as a sql tuning exercise.

Most often the root problem is imbalance in partitioning the query among the slaves. Better table stats and use of histograms would be the first thing I would check.

• ricky

Jonathan Lewis wrote:
>
> The "PX Deq Credit: send blkd" is not necessarily
> an idle event, and can be indicative of a sub-optimal
> parallel execution plan.
>
> The significance of "Send Blkd" is that the process
> has some information to forward and it is being
> blocked. If this occurs in the "parallel to serial"
> stage of a "QC (range)" transfer, then it is an
> idle event, and the processes that are waiting
> their turn will be ticking over on this event every
> 2 seconds. If it is in a "parallel to parallel" phase,
> then each block is a time-wasting block, will
> affect total throughput time, and probably incurs
> the overhead of an o/s task switch.
>
>
> Ricky Sanchez wrote in message <3D09555E.2303AF3C_at_more.net>...
> >Indeed these are parallel query events. With respect to the database
> >they can be ignored as "idle events". If parallel query is a performance
> >issue for you, approach it as a sql tuning exercise instead of a
> >database tuning issue.
> >
Received on Sun Jun 16 2002 - 20:19:58 CDT