[native pos] Fail, not hang, broadcast queries

[mbasmanova]

Broadcast queries used to hang forever. Now these queries fail quickly with a clear error message:

Broadcast shuffle is not supported

Also, check for replicate-nulls-and-any shuffle mode and reject these queries as well.

== NO RELEASE NOTE ==

[shrinidhijoshi]

Isn't it better to implement this check before the query execution starts (AbstractPrestoSparkQueryExecution.java#L785 )?, than during task-execution ?

[mbasmanova]

Isn't it better to implement this check before the query execution starts than during task-execution ?

This is a good question. It would be nice to avoid duplicating the logic of what's supported and what is not. One option is to add an API to Prestissimo to check if plan fragment is supported. Then use this API on the driver to check that all fragments are supported before starting query execution.

[shrinidhijoshi]

That would be ideal that this information lies with prestissimo.
We will have to add it as hardcoded list/java-logic in the presto-native-execution module, given we don't really have any instance of prestissimo worker running during query planning phase.

[mbasmanova]

We will have to add it as hardcoded list/java-logic in the presto-native-execution module, given we don't really have any instance of prestissimo worker running during query planning phase.

I think we can make changes to start native process on the driver for the purpose of plan validation. (We can also use it for constant folding of expressions that use external functions.)

[shrinidhijoshi]

I am split between just hardcoding the info (simple but hardcoded) of whats currently supported v/s starting a sidecar to evaluate this info (complex but clean)

We can also use it for constant folding of expressions that use external functions.

This might be a strong reason to add sidecar. I don't understand this use-case fully. Is there no other way to accomplish this.

[shrinidhijoshi]

Thanks @mbasmanova for explaining constant folding of expressions, for external functions. Looks like we will need Velox library to evaluate these during planning. So makes sense that we have to go with sidecar approach.

Do you want to still merge this PR ? This one might become throwaway work once we implement the sidecar solution.

[mbasmanova]

This one might become throwaway work once we implement the sidecar solution.

I think we still need to have proper checks in the C++ process as it cannot rely on the client (Java process) to always behave well.

[shrinidhijoshi]

LGTM! Thanks for working on this

[xiaoxmeng]

@mbasmanova LGTM. thanks!