-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Conversation
69cd57d
to
4f21a30
Compare
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.
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.
presto-main/src/main/java/com/facebook/presto/util/GraphvizPrinter.java
Outdated
Show resolved
Hide resolved
@@ -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) { |
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.
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?
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.
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.
presto-main/src/main/java/com/facebook/presto/sql/planner/optimizations/IndexJoinOptimizer.java
Show resolved
Hide resolved
presto-main/src/main/java/com/facebook/presto/sql/planner/planPrinter/PlanPrinter.java
Outdated
Show resolved
Hide resolved
presto-main/src/main/java/com/facebook/presto/sql/planner/plan/Assignments.java
Outdated
Show resolved
Hide resolved
return new VariableReferenceExpression(name, type); | ||
} | ||
|
||
public static Symbol toSymbol(VariableReferenceExpression variable) |
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.
Same here
import static com.google.common.base.Preconditions.checkState; | ||
import static java.util.stream.Collectors.toMap; | ||
|
||
public final class RowExpressionSymbolInliner |
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.
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)) { |
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.
An optimizer rule should only handle Expression
; otherwise it's bug. remove the else
branch.
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.
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?
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.
Then use castToRowExpression
in the test. Check TestEffectivePredicateExtractor
presto-main/src/main/java/com/facebook/presto/sql/planner/SymbolAllocator.java
Outdated
Show resolved
Hide resolved
@@ -784,6 +799,13 @@ public static Expression expression(String sql, ParsingOptions options) | |||
.collect(toImmutableList()); | |||
} | |||
|
|||
public CallExpression arithmeticCall(OperatorType type, RowExpression left, RowExpression right) |
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.
There are helpers available in StandardFunctionResolution
fc18e24
to
4a641bb
Compare
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.
"Extract ApplyNode::isSupportedSubqueryExpression to uility" does not compile
presto-main/src/main/java/com/facebook/presto/sql/relational/SqlToRowExpressionTranslator.java
Outdated
Show resolved
Hide resolved
presto-main/src/test/java/com/facebook/presto/cost/TestCostCalculator.java
Outdated
Show resolved
Hide resolved
e9f657e
to
edf2897
Compare
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.
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.
presto-main/src/main/java/com/facebook/presto/sql/planner/optimizations/ApplyNodeUtil.java
Outdated
Show resolved
Hide resolved
presto-main/src/test/java/com/facebook/presto/cost/TestCostCalculator.java
Outdated
Show resolved
Hide resolved
7c5fa69
to
97e88ef
Compare
869bab4
to
5e54d7a
Compare
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.
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?
presto-main/src/test/java/com/facebook/presto/cost/TestCostCalculator.java
Outdated
Show resolved
Hide resolved
...o-main/src/main/java/com/facebook/presto/sql/planner/sanity/ValidateDependenciesChecker.java
Show resolved
Hide resolved
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.
"Move identity functions into AssignmentUtils" LGTM
presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/InlineProjections.java
Outdated
Show resolved
Hide resolved
btw could you also resolve the conflicts? |
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.
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 % minor comments; make sure to clean up SymbolsExtractor
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.