Adding a table to a join removes parallel execution

From: Sébastien de Mapias <sglrigaud_at_gmail.com>
Date: Wed, 5 Jun 2013 05:43:55 -0700 (PDT)
Message-ID: <d8190634-2432-44fb-a65d-ada4aa6ed4d5_at_j8g2000vbl.googlegroups.com>



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 Received on Wed Jun 05 2013 - 14:43:55 CEST

Original text of this message