Speed up planner's scanning for parallel-query hazards.
We need to scan the whole parse tree for parallel-unsafe functions. If there are none, we'll later need to determine whether particular subtrees contain any parallel-restricted functions. The previous coding retained no knowledge from the first scan, even though this is very wasteful in the common case where the query contains only parallel-safe functions. We can bypass all of the later scans by remembering that fact. This provides a small but measurable speed improvement when the case applies, and shouldn't cost anything when it doesn't. Patch by me, reviewed by Robert Haas Discussion: <3740.1471538387@sss.pgh.pa.us>
Showing
- src/backend/nodes/outfuncs.c 1 addition, 0 deletionssrc/backend/nodes/outfuncs.c
- src/backend/optimizer/path/allpaths.c 4 additions, 26 deletionssrc/backend/optimizer/path/allpaths.c
- src/backend/optimizer/plan/planmain.c 4 additions, 5 deletionssrc/backend/optimizer/plan/planmain.c
- src/backend/optimizer/plan/planner.c 29 additions, 14 deletionssrc/backend/optimizer/plan/planner.c
- src/backend/optimizer/util/clauses.c 86 additions, 29 deletionssrc/backend/optimizer/util/clauses.c
- src/backend/optimizer/util/pathnode.c 3 additions, 3 deletionssrc/backend/optimizer/util/pathnode.c
- src/backend/optimizer/util/relnode.c 2 additions, 2 deletionssrc/backend/optimizer/util/relnode.c
- src/include/nodes/relation.h 2 additions, 0 deletionssrc/include/nodes/relation.h
- src/include/optimizer/clauses.h 2 additions, 1 deletionsrc/include/optimizer/clauses.h
Loading
Please register or sign in to comment