Skip to content
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

refactor(expr): don't fallback to evaluation by row on error #14174

Merged
merged 3 commits into from
Dec 28, 2023

Conversation

wangrunji0408
Copy link
Contributor

@wangrunji0408 wangrunji0408 commented Dec 25, 2023

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

resolve #14027 and replace #14147

This PR introduces a MultiExprError to collect function errors by each row. The NonStrict wrapper can identify this error and return partial results without falling back to evaluation row by row.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Comment on lines +106 to +113
Err(ExprError::Multiple(array, errors)) => {
for error in errors {
self.report.report(error);
}
array
}
Err(e) => {
self.report.report(e);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we ensure that (almost) all Expressions return Multiple? Otherwise, all rows will be padded with NULL once there's an error.

Copy link
Contributor Author

@wangrunji0408 wangrunji0408 Dec 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I have checked that. The remaining expressions not generated by #[function] are not evaluated row by row, except for UDF, which I will fix later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks so fragile to me. 🥵

@@ -34,7 +34,8 @@ use crate::{bail, ExprError, Result};

/// Build an expression from protobuf.
pub fn build_from_prost(prost: &ExprNode) -> Result<BoxedExpression> {
ExprBuilder::new_strict().build(prost)
let expr = ExprBuilder::new_strict().build(prost)?;
Ok(Strict::new(expr).boxed())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this step into the ExprBuilder?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wrapper is only needed at the top level. So I think no need to move it into the builder?

impl MultiExprError {
/// Returns the first error.
pub fn first(self) -> ExprError {
self.0.into_vec().into_iter().next().expect("first error")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
self.0.into_vec().into_iter().next().expect("first error")
self.0.into_iter().next().expect("first error")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If removed, the item would be &ExprError. Seems to be a historical problem rust-lang/rust#59878

Signed-off-by: Runji Wang <[email protected]>
@wangrunji0408 wangrunji0408 added this pull request to the merge queue Dec 28, 2023
Merged via the queue into main with commit ee6c1e9 Dec 28, 2023
27 of 28 checks passed
@wangrunji0408 wangrunji0408 deleted the wrj/dont-fallback-eval-row branch December 28, 2023 04:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

expr: don't fallback to evaluation by row on error
3 participants