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

Replace Expression with RowExpression in assignment #12747

Merged
merged 11 commits into from
Jun 18, 2019

Conversation

hellium01
Copy link
Contributor

@hellium01 hellium01 commented Apr 30, 2019

A update on top of #12715. Will squash after review. Some utility was borrowed from another PR which will be removed once rebased on top of each other.

@hellium01 hellium01 force-pushed the FixProject branch 5 times, most recently from 69cd57d to 4f21a30 Compare May 2, 2019 02:38
@hellium01 hellium01 changed the title [WIP] Use RowExpression in assignment Use RowExpression in assignment May 2, 2019
@hellium01 hellium01 requested a review from highker May 2, 2019 16:26
@hellium01 hellium01 changed the title Use RowExpression in assignment Replace Expression with RowExpression in assignment May 2, 2019
Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

Just did a high-level skim. This is a promising patch! No fundamental change at the moment. Vanishing the two Assignments.Builder commits should just work.

@@ -678,6 +678,10 @@ protected RowExpression visitInPredicate(InPredicate node, Void context)
{
ImmutableList.Builder<RowExpression> arguments = ImmutableList.builder();
arguments.add(process(node.getValue(), context));
if (node.getValueList() instanceof SymbolReference) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought about this as well. I'm just not sure originally where SymbolReference got replaced by InList. Could you add a comment here to explain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The related test is testDoubleNestedCorrelatedSubqueries. The query (nested correlated subqueries) in the test

SELECT orderkey FROM orders o WHERE 3 IN (SELECT o.custkey FROM lineitem l WHERE (SELECT l.orderkey = o.orderkey))

is not supported today (tested in master branch). Let me try to remove this from translator and do not do a expression to row expression translation for this test. We need to think how to fix this test in longer term though.

return new VariableReferenceExpression(name, type);
}

public static Symbol toSymbol(VariableReferenceExpression variable)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

import static com.google.common.base.Preconditions.checkState;
import static java.util.stream.Collectors.toMap;

public final class RowExpressionSymbolInliner
Copy link
Contributor

Choose a reason for hiding this comment

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

Make the util (with its tests) as a separate commit "Introduce RowExpressionSymbolInliner".

Symbol symbol = context.getSymbolAllocator().newSymbol(translatedExpression, type);
projections.put(symbol, castToRowExpression(translatedExpression));
Symbol symbol;
if (isExpression(translatedExpression)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

An optimizer rule should only handle Expression; otherwise it's bug. remove the else branch.

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 commit might not be named correctly. It is update mainly because the test was updated to use RowExpression. Given we are migrating Expression to RowExpression. It should be only beneficial if we handle RowExpression as well here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Then use castToRowExpression in the test. Check TestEffectivePredicateExtractor

@@ -784,6 +799,13 @@ public static Expression expression(String sql, ParsingOptions options)
.collect(toImmutableList());
}

public CallExpression arithmeticCall(OperatorType type, RowExpression left, RowExpression right)
Copy link
Contributor

Choose a reason for hiding this comment

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

There are helpers available in StandardFunctionResolution

Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

"Extract ApplyNode::isSupportedSubqueryExpression to uility" does not compile

Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

Can we keep the momentum of this patch and #12710? Even these two patches are blocked by variable refactoring, it's good to address logic errors earlier.

@hellium01 hellium01 force-pushed the FixProject branch 3 times, most recently from 7c5fa69 to 97e88ef Compare May 22, 2019 06:48
@hellium01 hellium01 requested a review from highker May 22, 2019 19:15
Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

Reviewed all commits up to "Remove unused getOutputSymbols" (incl.). Two major comments:

  • The change of ValidateDependenciesChecker is a bit concerning. What is the motivation for that? In general we should fix the codebase or rule rather than relaxing the check.
  • The timestamps for commits are out of order. Could you fix it?

@highker highker self-requested a review June 17, 2019 22:29
Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

"Move identity functions into AssignmentUtils" LGTM

@highker
Copy link
Contributor

highker commented Jun 17, 2019

btw could you also resolve the conflicts?

@highker highker self-requested a review June 18, 2019 00:23
hellium01 and others added 11 commits June 17, 2019 17:24
checkDependencies checks if referenced variables in assignment are same
as input. If the assignment is type only cast (for example cast
varchar(3) to varchar(5)), the referenced variable will be implicitly
changed to target type.

Reading symbol1, VARCHAR(3) input into symbol1 VARCHAR(5) still
should be OK. Simple containsAll works when input is considered
as symbol will fail when we add in the type checks.
We don't support correlated subquery with multiple correlated columns.
Instead expect it to return a invalid plan, expect an exception.
Copy link
Contributor

@highker highker left a comment

Choose a reason for hiding this comment

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

LGTM % minor comments; make sure to clean up SymbolsExtractor

@hellium01 hellium01 merged commit ad7382b into prestodb:master Jun 18, 2019
@hellium01 hellium01 deleted the FixProject branch June 18, 2019 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants