Re: Adding a table to a join removes parallel execution

From: ddf <oratune_at_msn.com>
Date: Wed, 5 Jun 2013 06:53:34 -0700 (PDT)
Message-ID: <376ec148-059d-4f22-ad60-349fcfa621b4_at_googlegroups.com>

On Wednesday, June 5, 2013 6:43:55 AM UTC-6, Sébastien de Mapias wrote:
> Hello,
>
>
>
> In 10gR2, we had a view with a four-table join that the optimizer used
>
> to resolve with parallel processing when queried; we've added another
>
> table to the FROM, and now a trace shows that there's no more parallel
>
> execution whatsoever. I can't understand why: before giving further
>
> details here I would like to hear if someone has any idea as to why
>
> the optimizer gets rid of this parallel execution plan (I suspect that
>
> it no more has the time to try other join permutations and realize
>
> it's better with parallel, but i'm not sure, and *important*: the
>
> hints haven't been modified and there is indeed a hint specifying a
>
> parallel degree on a certain table - which is now ignored !).
>
>
>
> The WHERE clauses ("select /*+ parallel(...) */ ... from view where
>
> col_a = '...' and col_b = '...') are the same in both versions of this
>
> view. The table added to the view definition is empty and is outer
>
> joined (it's supposed to be populated little by little in the future).
>
>
>
> Thanks a lot.
>
> Regards,
>
> Seb

I no longer have 10.2 installed to play with and doing what you report in 11.2 still provides parallel execution.

We will need much more information from you.

David Fitzjarrell Received on Wed Jun 05 2013 - 15:53:34 CEST