Problem
Velox has separate registration paths for common cuDF functions and Presto-specific cuDF functions:
velox::cudf_velox::registerCudf();
velox::cudf_velox::registerPrestoFunctions(...);
Presto native currently initializes cuDF by calling velox::cudf_velox::registerCudf(), but it does not call velox::cudf_velox::registerPrestoFunctions() in the cuDF startup path.
As a result, Presto-specific cuDF functions are not registered when cuDF is enabled in Presto native.
Proposed fix
Call registerPrestoFunctions() after registerCudf() in registerVeloxCudf(), using the configured cuDF function name prefix:
velox::cudf_velox::registerCudf();
velox::cudf_velox::registerPrestoFunctions(
velox::cudf_velox::CudfConfig::getInstance().functionNamePrefix);
This keeps the Presto-specific cuDF registration next to the existing cuDF initialization and preserves the configured Presto function namespace.
Context
A small PR with the proposed change was opened here for reference, but could not proceed because of CLA authorization on the submitter account:
Problem
Velox has separate registration paths for common cuDF functions and Presto-specific cuDF functions:
Presto native currently initializes cuDF by calling
velox::cudf_velox::registerCudf(), but it does not callvelox::cudf_velox::registerPrestoFunctions()in the cuDF startup path.As a result, Presto-specific cuDF functions are not registered when cuDF is enabled in Presto native.
Proposed fix
Call
registerPrestoFunctions()afterregisterCudf()inregisterVeloxCudf(), using the configured cuDF function name prefix:This keeps the Presto-specific cuDF registration next to the existing cuDF initialization and preserves the configured Presto function namespace.
Context
A small PR with the proposed change was opened here for reference, but could not proceed because of CLA authorization on the submitter account: