Presto C++ can only be used as a worker but not as a coordinator?

[linghengqian]

Describe the problem you faced

• I'm trying to compile Presto JDBC Driver into GraalVM Native Image. When I looked at https://github.com/prestodb/presto/blob/0.289/presto-native-execution/testcontainers/README.md, I noticed a command like this.

To run the functional tests using existing docker images, specify -DcoordinatorImage and -DworkerImage in the run/debug configurations of the test as VM options. For example:

-DcoordinatorImage="public.ecr.aws/oss-presto/presto:0.287-20240619190653-db8458d" -DworkerImage="public.ecr.aws/oss-presto/presto-native:0.287-20240619190653-db8458d"

• Does this command mean that Presto C++ can only be used as a worker but not as a coordinator?
• I'm not sure if there are any additional limitations. If this is a known limitation, can I try to compile Presto Server as a GraalVM Native Image and use this gcc debuggable C/C++ program as the coordinator? Can this also ensure that both the worker and coordinator are VM-free programs?

Environment Description

• Presto version used: 0.289
• Storage (HDFS/S3/GCS..): Um, the storage inside the Docker Image should be memory-level?
• Data source and connectors or catalogs used: Memory Connector
• Deployment (Cloud or On-prem): On-prem
• Pastebin link to the complete debug logs: Maybe not.

Steps To Reproduce

Steps to reproduce the behavior:

1. Open https://github.com/prestodb/presto/blob/0.289/presto-native-execution/testcontainers/README.md#2-run-functional-tests .

Expected behavior

• A more explicit clarification should be present in the relevant MarkDown documentation.

Additional context

• This is essentially an extended investigation of Improve GraalVM Reachability Metadata and corresponding nativeTest related unit tests apache/shardingsphere#29052 .

Stacktrace

• Null.

[elharo]

Correct. Presto C++ is only for the worker, not the coordinator.

As to GraalVM, you're welcome to try. Might work, might not. IMHO it's not likely that would be the path forward for the entire project — mostly we're happy with a pure Java coordinator — but you never know.