Re: Parallel query on when it's not supposed to be (?)

I'm with Mark. If you're seeing stuff like "parallel execution dequeue wait" all you're seeing is a wait for all of the parallel slaves do actually do all (most) of the work. I don't think the calling session really has all that much to do during a query that get's parallelized so it's pretty easy for things like this to dominate the wait time. I hesitate to call it "idle" because that makes it too easy to disregard and Cary and others have shown what can happen there. I'd think of it as more of a "placeholder" wait and concentrate on what parallel slaves are waiting on. This is really nasty because parallel execution slaves persist get reused and I don't know how to deliniate waits in something like 10046 between different queries, so on a production server I'd have to do some serious digging.

As for doing more reads, I'm pretty sure PQ bypasses the buffer cache so in addition to having sufficient CPU capacity you better have IO bandwidth to spare as well.

S-

On Wed, 15 Sep 2004, Mark Richard wrote:

> I just wanted to pose a question to anyone on the list (particular the wait
> event guru's like Cary)...
>
> Eliminating parallel query because you are seeing waits for it sounds to me
> a little like tuning the BCHR. I can't help but wonder if waiting for a
> parallel query is still the quickest way to get things done? Would killing
> the parallel query effectively move the waits to another category without
> achieving any real gain?
>
> Regards,
> Mark.

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