-
Notifications
You must be signed in to change notification settings - Fork 590
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
feat(optimizer): improve scalar subqueries optimization time #16966
feat(optimizer): improve scalar subqueries optimization time #16966
Conversation
if let Some(join) = plan.as_logical_join() { | ||
Self::rewrite_join( | ||
join, | ||
left_idxs, | ||
offset, | ||
index_mapping, | ||
data_types, | ||
index, | ||
) | ||
} else if let Some(apply) = plan.as_logical_apply() { | ||
Self::rewrite_apply( | ||
apply, | ||
left_idxs, | ||
offset, | ||
index_mapping, | ||
data_types, | ||
index, | ||
) | ||
} else if let Some(scan) = plan.as_logical_scan() { | ||
Self::rewrite_scan( | ||
scan, | ||
left_idxs, | ||
offset, | ||
index_mapping, | ||
data_types, | ||
index, | ||
) |
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.
Are these lines duplicated with the lambda rewrite
?
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.
Let me refactor that. Thanks for pointing it out.
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.
LGTM
└─BatchExchange { order: [], dist: HashShard(t.arr) } | ||
└─BatchScan { table: t, columns: [t.arr], distribution: SomeShard } | ||
└─BatchExchange { order: [], dist: HashShard(t.arr) } | ||
└─BatchScan { table: t, columns: [t.arr], distribution: SomeShard } |
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.
Curious why this plan gets improved?
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.
Because the initial logical plan of this case is:
LogicalProject { exprs: [t.x, t.arr, unnest, ordinality, unnest, ordinality] }
└─LogicalApply { type: Inner, on: true, correlated_id: 1 }
├─LogicalApply { type: Inner, on: true, correlated_id: 2 }
│ ├─LogicalScan { table: t, columns: [x, arr, _row_id] }
│ └─LogicalTableFunction { table_function: Unnest(CorrelatedInputRef { index: 1, correlated_id: 2 }) }
└─LogicalTableFunction { table_function: Unnest(CorrelatedInputRef { index: 1, correlated_id: 1 }) }
It is the same shape as the multi scalar subqueries.
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Apply
. As a result, it is hard to find the original domain for the upperApply
operator. In this PR, we try to translate theApply
in a top-down order and simplify the domain by extracting the domain from the apply input. In this way, optimization time could linearly increase as the number of scalar subqueries grows.Checklist
./risedev check
(or alias,./risedev c
)Documentation
Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.