-
Notifications
You must be signed in to change notification settings - Fork 22
ADBDEV-6886: Add support parameterized clauses in the subplan with volatile functions #1240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: adb-7.2.0
Are you sure you want to change the base?
Changes from all commits
2883755
f8a4d94
0586525
00bb1b4
6ab3bad
37994ac
cec1a6d
f30f637
84cd382
2b22a31
47b8dee
1f09942
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -522,9 +522,21 @@ bring_to_outer_query(PlannerInfo *root, RelOptInfo *rel, List *outer_quals) | |
| Path *path; | ||
| CdbPathLocus outerquery_locus; | ||
|
|
||
| if (CdbPathLocus_IsGeneral(origpath->locus) || | ||
| CdbPathLocus_IsOuterQuery(origpath->locus)) | ||
| /* | ||
| * We can change the locus and add Motion here if we need OuterQuery. | ||
| * However, if there is a volatile function in TL, we should do this | ||
| * later. The reason for this is that the volatile function in this | ||
| * case can be in the Result node (for each segment). We want the | ||
| * volatile function to be executed once if possible. So, the locus | ||
| * change and Motion addition occurs later after the scan/join path | ||
| * is generated (see cdbpath_create_motion_to_outer_query()). | ||
| */ | ||
| if (CdbPathLocus_IsGeneral(origpath->locus) || CdbPathLocus_IsOuterQuery(origpath->locus) || | ||
| ((CdbPathLocus_IsSegmentGeneral(origpath->locus) || CdbPathLocus_IsSingleQE(origpath->locus)) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
taken into account? I suggest just to test join plans to find some side effects of this condition. At first glance nothing drastic happens.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
without patch: postgres=# explain (costs off, verbose) SELECT (SELECT f(t_repl.i) from t_repl join t_strewn using(i) where t_repl.j < few.id) FROM few;
QUERY PLAN
-----------------------------------------------------------------------------
Gather Motion 3:1 (slice1; segments: 3)
Output: ((SubPlan 1))
-> Seq Scan on public.few
Output: (SubPlan 1)
SubPlan 1
-> Hash Join
Output: f(t_repl.i)
Hash Cond: (t_repl.i = t_strewn.i)
-> Result
Output: t_repl.i, t_repl.j
Filter: (t_repl.j < few.id)
-> Materialize
Output: t_repl.i, t_repl.j
-> Broadcast Motion 1:3 (slice2; segments: 1)
Output: t_repl.i, t_repl.j
-> Seq Scan on public.t_repl
Output: t_repl.i, t_repl.j
-> Hash
Output: t_strewn.i
-> Materialize
Output: t_strewn.i
-> Broadcast Motion 3:3 (slice3; segments: 3)
Output: t_strewn.i
-> Seq Scan on public.t_strewn
Output: t_strewn.iwith (checkMotionWithParam is off): Gather Motion 3:1 (slice1; segments: 3)
Output: ((SubPlan 1))
-> Seq Scan on public.few
Output: (SubPlan 1)
SubPlan 1
-> Result
Output: f(t_repl.i)
-> Materialize
Output: t_repl.i
-> Broadcast Motion 3:3 (slice2; segments: 3)
Output: t_repl.i
-> Hash Join
Output: t_repl.i
Hash Cond: (t_repl.i = t_strewn.i)
-> Result
Output: t_repl.i, t_repl.j
Filter: (t_repl.j < few.id)
-> Seq Scan on public.t_repl
Output: t_repl.i, t_repl.j
-> Hash
Output: t_strewn.i
-> Seq Scan on public.t_strewn
Output: t_strewn.i |
||
| && contain_volatile_functions((Node *) root->processed_tlist))) | ||
| { | ||
| path = origpath; | ||
| } | ||
| else | ||
| { | ||
| /* | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment says "non-top slice". Is there the case when we could mistakenly omit the motion in case of
context->sliceDepth > 0 && motion->plan.lefttree->flow->locustype == CdbLocusType_SingleQE?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, the condition is weakened. But is there a way to strictly identify our specific case with motion?