|
Hi!
Increasing it from it's default won't probaly
help to get a better execution plan, unless you have 10-way or even more
complex joins.
However, having a large value of this parameter
with complex joins can push your parse times (QEP calculations) very
high!
That's why one has to reduce it from 80000 to 2000
in latest Oracle Apps versions for example.
And reducing it in
regular apps with not-so-complex joins won't kill either, because a 7-way join
can be evaluated in 7! = 5040 permutations and Oracle uses several optimization
mechanisms such QEP early elimination, join order intermediate cutoffs, putting
cartesian joins last in evaluation sequence if there's more tables in join
than specified by _optimizer_search_limit parameter, etc..
I'd say you definitely get the best plan (in CBO
sense) with optimizer_max_permutations when doint 8-way joins, you probably get
the best plan even with 9-way joins, and you get near-the-best plan with higher,
10-12 ones too, thanks to internal optimizations in finding the optimal
plan.
Tanel.
|
Title: Message
- optimizer_max_permutations Boivin, Patrice J
- Re: optimizer_max_permutations Tanel Poder
- Re: optimizer_max_permutations Connor McDonald
- Re: optimizer_max_permutations Jared Still
- RE: optimizer_max_permutations John Kanagaraj
- Re: optimizer_max_permutations Tanel Poder
- RE: optimizer_max_permutations Post, Ethan
- RE: optimizer_max_permutations Boivin, Patrice J
