docs: optimizer_join_order guc #4014
Conversation
| @@ -29,6 +29,8 @@ | |||
| aggregate plan for a scalar distinct qualified aggregate. </li> | |||
| <li><codeph>optimizer_force_three_stage_scalar_dqa</codeph> forces GPORCA to choose a plan | |||
| with multistage aggregates when such a plan alternative is generated. </li> | |||
| <li><codeph>optimizer_join_order</codeph> sets the optimization level for join ordering during | |||
There was a problem hiding this comment.
Seems like there's one too many "optimization's" here. How about: optimizer_join_order sets the query optimization level for join ordering by specifying which types of join ordering alternatives to evaluate.
| </ul> | ||
| <p>The default value is <codeph>exhaustive</codeph>. Setting this parameter to | ||
| <codeph>query</codeph> or <codeph>greedy</codeph> can generate a suboptimal | ||
| query plan. </p> |
There was a problem hiding this comment.
Seems like we should provide some rationale for changing the default. I'm guessing it would reduce the time spent in optimizing certain queries?
|
@litzell @vraghavan78 Also FYI - there is this issue wrt optimizer_join_order_threshold |
| <codeph>query</codeph> or <codeph>greedy</codeph> can generate a suboptimal | ||
| query plan. However, if the administrator is confident that a satisfactory plan | ||
| is generated with the <codeph>query</codeph> or <codeph>greedy</codeph> setting, | ||
| query performance can be improved by setting the parameter to the lower |
There was a problem hiding this comment.
query optimization time can be improved ....
|
when you set it to greedy/query it will override
The issue you mentioned is orthogonal to join optimization levels so now worries there |
|
@litzell @vraghavan78 |
* docs: optimizer_join_order guc * Implement suggested edits * Note iteractions with other params; correct inaccurate statement. * Clarify this is a GPORCA guc
Adds docs for new optimizer_join_order guc