Skip to content

[native] Handle NULLIF without the need for specialForm#19791

Merged
vermapratyush merged 2 commits intoprestodb:masterfrom
vermapratyush:null-if
Jun 29, 2023
Merged

[native] Handle NULLIF without the need for specialForm#19791
vermapratyush merged 2 commits intoprestodb:masterfrom
vermapratyush:null-if

Conversation

@vermapratyush
Copy link
Member

@vermapratyush vermapratyush commented Jun 5, 2023

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 ), cast(second as )), cast(null as firstType), first)

Extend TestExpressionCompiler to native test suite with addition of nullIf in
GeneralQueries test suite.

== NO RELEASE NOTE ==

@feilong-liu feilong-liu self-requested a review June 5, 2023 21:35
@vermapratyush vermapratyush reopened this Jun 15, 2023
@vermapratyush vermapratyush changed the title [native] Add additional cast to NULL_IF is argument types are different [native] Handle NULLIF without the need for specialForm Jun 22, 2023
@vermapratyush vermapratyush requested a review from rschlussel June 22, 2023 12:15
@vermapratyush vermapratyush marked this pull request as ready for review June 22, 2023 12:16
@vermapratyush vermapratyush requested review from a team as code owners June 22, 2023 12:16
@vermapratyush vermapratyush requested a review from presto-oss June 22, 2023 12:16
@vermapratyush vermapratyush force-pushed the null-if branch 7 times, most recently from 12191ca to 997f175 Compare June 26, 2023 15:50
Copy link
Contributor

@rschlussel rschlussel left a comment

Choose a reason for hiding this comment

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

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).

Copy link
Contributor

Choose a reason for hiding this comment

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

Are these all things that need to be fixed for native? Should we create an issue and link it in the comment here?

Copy link
Member Author

@vermapratyush vermapratyush Jun 27, 2023

Choose a reason for hiding this comment

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

Created an issue and added it to comment. #19999

Copy link
Contributor

Choose a reason for hiding this comment

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

@majetideepak Deepak, is this something you could help look into?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@mbasmanova sure.

Copy link
Contributor

Choose a reason for hiding this comment

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

can you clarify this? Shouldn't they still pass even if they don't have custom handling?

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@rschlussel rschlussel left a comment

Choose a reason for hiding this comment

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

Never mind about not being able to find the main change. Looks like it was a temporary state while you were updating the branch.

@rschlussel
Copy link
Contributor

also fix checkstyle violations

@vermapratyush vermapratyush force-pushed the null-if branch 3 times, most recently from 5b1e24b to b61e779 Compare June 27, 2023 12:24
@vermapratyush vermapratyush requested a review from rschlussel June 27, 2023 13:02
@vermapratyush
Copy link
Member Author

The test failure is unrelated to this change, I am looking at fixing the test here. #20003

Optional.empty(),
sqlFunctionProperties,
sessionFunctions,
false,
Copy link
Contributor

Choose a reason for hiding this comment

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

is this safe to assume it's not native?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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 ?

Copy link
Member Author

Choose a reason for hiding this comment

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

@aditi-pandit Can you please elaborate what do you mean by can we use that property instead of this rule?

Copy link
Contributor

Choose a reason for hiding this comment

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

@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 ?

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@rschlussel rschlussel left a comment

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't we address this TODO now?

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@mbasmanova mbasmanova left a comment

Choose a reason for hiding this comment

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

@vermapratyush There was custom translation of NULLIF expression in Prestissimo. I assume we do not need this anymore. Let's remove.

Copy link
Contributor

@mbasmanova mbasmanova left a comment

Choose a reason for hiding this comment

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

@rschlussel @vermapratyush Do you have a sense of any performance penalty this implementation of NULLIF would have?

@rschlussel
Copy link
Contributor

@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)

Copy link
Contributor

Choose a reason for hiding this comment

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

These tests look very similar to me. What's the motivation for adding so many nearly identical tests?

Copy link
Member Author

@vermapratyush vermapratyush Jun 29, 2023

Choose a reason for hiding this comment

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

They are permutation combination of bigint, double and empty rows (see date filter).

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.
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.

5 participants