[native] Handle NULLIF without the need for specialForm#19791
[native] Handle NULLIF without the need for specialForm#19791vermapratyush merged 2 commits intoprestodb:masterfrom
Conversation
12191ca to
997f175
Compare
rschlussel
left a comment
There was a problem hiding this comment.
can't find the actual change. can you point me to which file it's in? also, can you add an end to end test to AbstractTestQueries to make sure a full query will work (I think presto native extends/runs all those queries, right? if not, then some equivalent to add a test for both java and for native implementations).
There was a problem hiding this comment.
Are these all things that need to be fixed for native? Should we create an issue and link it in the comment here?
There was a problem hiding this comment.
Created an issue and added it to comment. #19999
There was a problem hiding this comment.
@majetideepak Deepak, is this something you could help look into?
There was a problem hiding this comment.
can you clarify this? Shouldn't they still pass even if they don't have custom handling?
There was a problem hiding this comment.
They still pass, but running them seems redundant as there is no custom handling. The queries gets executed within JVM (constant folding) and does not touch the cpp server.
presto-main/src/main/java/com/facebook/presto/sql/relational/SqlToRowExpressionTranslator.java
Outdated
Show resolved
Hide resolved
rschlussel
left a comment
There was a problem hiding this comment.
Never mind about not being able to find the main change. Looks like it was a temporary state while you were updating the branch.
presto-main/src/test/java/com/facebook/presto/sql/gen/TestExpressionCompiler.java
Outdated
Show resolved
Hide resolved
...ution/src/test/java/com/facebook/presto/nativeworker/TestPrestoNativeGeneralQueriesJSON.java
Outdated
Show resolved
Hide resolved
|
also fix checkstyle violations |
5b1e24b to
b61e779
Compare
|
The test failure is unrelated to this change, I am looking at fixing the test here. #20003 |
presto-main/src/main/java/com/facebook/presto/sql/analyzer/StatementAnalyzer.java
Show resolved
Hide resolved
| Optional.empty(), | ||
| sqlFunctionProperties, | ||
| sessionFunctions, | ||
| false, |
There was a problem hiding this comment.
is this safe to assume it's not native?
There was a problem hiding this comment.
I don't see this code path being triggered in native path.
It is used in
- https://github.com/vermapratyush/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/InlineSqlFunctions.java#L106
https://github.com/prestodb/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/InlineSqlFunctions.java#L106 - should not be invoked in native flow - https://github.com/vermapratyush/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/gen/RowExpressionCompiler.java#L144
https://github.com/prestodb/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/gen/RowExpressionCompiler.java#L144 - should not be invoked in native flow - https://github.com/vermapratyush/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/planner/RowExpressionInterpreter.java#L282
https://github.com/prestodb/presto/blob/d5eed561c31e21cb0b6cfa5f94038d9d4f2b4b89/presto-main/src/main/java/com/facebook/presto/sql/planner/RowExpressionInterpreter.java#L282 - Not sure about this one (i don’t see this getting invoked from the e2e unit tests)
Do you know if RowExpressionInterpreter is of concern?
There was a problem hiding this comment.
I think these can be invoked from native flow if someone uses a sql function that uses NULLIF in its implementation. And seems like an easy place for bugs to lurk.
There was a problem hiding this comment.
Could this be because all the native tests set configuration "inline-sql-functions" to false ? https://github.com/prestodb/presto/blob/master/presto-native-execution/src/test/java/com/facebook/presto/nativeworker/NativeQueryRunnerUtils.java#L32
Ideally, we should try to avoid such properties/configurations.
But is it possible to use that property instead in this rule ?
There was a problem hiding this comment.
@aditi-pandit Can you please elaborate what do you mean by can we use that property instead of this rule?
There was a problem hiding this comment.
@vermapratyush : I'm not super familiar with optimizer code, but it is possible that instead of hardcoding to false, we get the value for inline-sql-functions property at a higher level (or here itself if there is access to it) and use that instead in this code ?
There was a problem hiding this comment.
The issue with inline-sql-functions is the same as that of using Session to determine if the query is for native, certain code-flow does not have session object.
I also verified with the velox team, and it would not make sense to provide support for SQL function for native queries within the java stack. It is better to support sql function by implementing it natively in velox itself. So I think hard-coding is ok here.
...e-execution/src/test/java/com/facebook/presto/spark/TestPrestoSparkNativeGeneralQueries.java
Outdated
Show resolved
Hide resolved
5ed517c to
c15e61a
Compare
rschlussel
left a comment
There was a problem hiding this comment.
Summarizing discussion:
This fixes handling of NULLIF for native for all code paths that native queries currently go through. The SqlFunctionUtils, which are used in the sql function code path does not currently properly support native, since there is no access to the session there, only connector session. Sqlfunctions are disabled in native, so this path isn't currently accessed, but it's a place for surprise bugs for the future. This is still a todo to fix, but we don't want to block the main issue on addressing this case: #20008.
There was a problem hiding this comment.
Why can't we address this TODO now?
There was a problem hiding this comment.
Detailed conversation in this thread: https://github.com/prestodb/presto/pull/19791/files/189afe0a571d7ee128f242fd803a6098d967861b#r1243767843
In short,
The SqlFunctionUtils, which are used in the sql function code path does not currently properly support native, since there is no access to the session there, only connector session.
There was a problem hiding this comment.
the solution would be to add the isNative flag to the connector session and pass it through when we create the connector session. I think that's a very reasonable to do, and there may be other places that would want to handle things differently depending on the native flag too, so could be generally useful.
mbasmanova
left a comment
There was a problem hiding this comment.
@vermapratyush There was custom translation of NULLIF expression in Prestissimo. I assume we do not need this anymore. Let's remove.
mbasmanova
left a comment
There was a problem hiding this comment.
@rschlussel @vermapratyush Do you have a sense of any performance penalty this implementation of NULLIF would have?
it's doing the same translation that the custom cpp code is doing, so should be the same. Only overhead would be if it's adding casts that the cpp function doesn't need (e.g. type only coercion) |
There was a problem hiding this comment.
These tests look very similar to me. What's the motivation for adding so many nearly identical tests?
There was a problem hiding this comment.
They are permutation combination of bigint, double and empty rows (see date filter).
...e-execution/src/test/java/com/facebook/presto/spark/TestPrestoSparkNativeGeneralQueries.java
Outdated
Show resolved
Hide resolved
The usage of type coercion in NULLIF in presto/java made it incompatible with presto native, this was made possible by specialForm. Handle NULLIF in presto native using the expanded form: > if (equal(cast(first as <common type>), cast(second as <common type>)), cast( null as firstType), first) Extend TestExpressionCompiler to native test suite with addition of nullIf in GeneralQueries test suite.
The usage of type coercion in NULLIF in presto/java made it incompatible with
presto native, this was made possible by specialForm. Handle NULLIF in presto
native using the expanded form:
Extend TestExpressionCompiler to native test suite with addition of nullIf in
GeneralQueries test suite.