Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit4324ade

Browse files
committed
Fix optimization for skipping searches for parallel-query hazards.
Fix thinko in commitda1c916: even if the original query was free ofparallel hazards, we might introduce such a hazard by adding PARAM_EXECParam nodes. Adjust is_parallel_safe() so that it will scan the givenexpression whenever any such nodes have been created. Per report fromAndreas Seltenreich.Discussion: <878tse6yvf.fsf@credativ.de>
1 parenta734fd5 commit4324ade

File tree

1 file changed

+8
-2
lines changed

1 file changed

+8
-2
lines changed

‎src/backend/optimizer/util/clauses.c

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1150,8 +1150,14 @@ is_parallel_safe(PlannerInfo *root, Node *node)
11501150
{
11511151
max_parallel_hazard_contextcontext;
11521152

1153-
/* If max_parallel_hazard found nothing unsafe, we don't need to look */
1154-
if (root->glob->maxParallelHazard==PROPARALLEL_SAFE)
1153+
/*
1154+
* Even if the original querytree contained nothing unsafe, we need to
1155+
* search the expression if we have generated any PARAM_EXEC Params while
1156+
* planning, because those are parallel-restricted and there might be one
1157+
* in this expression. But otherwise we don't need to look.
1158+
*/
1159+
if (root->glob->maxParallelHazard==PROPARALLEL_SAFE&&
1160+
root->glob->nParamExec==0)
11551161
return true;
11561162
/* Else use max_parallel_hazard's search logic, but stop on RESTRICTED */
11571163
context.max_hazard=PROPARALLEL_SAFE;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp