Replace Expression with RowExpression in assignment #12747
Replace Expression with RowExpression in assignment #12747hellium01 merged 11 commits intoprestodb:masterfrom
Conversation
69cd57d to
4f21a30
Compare
highker
left a comment
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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
Outdated
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
There was a problem hiding this comment.
Make the util (with its tests) as a separate commit "Introduce RowExpressionSymbolInliner".
There was a problem hiding this comment.
An optimizer rule should only handle Expression; otherwise it's bug. remove the else branch.
There was a problem hiding this comment.
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.
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
There was a problem hiding this comment.
There are helpers available in StandardFunctionResolution
fc18e24 to
4a641bb
Compare
highker
left a comment
There was a problem hiding this comment.
"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
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
highker
left a comment
There was a problem hiding this comment.
Reviewed all commits up to "Remove unused getOutputSymbols" (incl.). Two major comments:
- The change of
ValidateDependenciesCheckeris 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
highker
left a comment
There was a problem hiding this comment.
"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.
highker
left a comment
There was a problem hiding this comment.
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.