-
Notifications
You must be signed in to change notification settings - Fork 5.5k
chore(ci): Advance velox #26584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(ci): Advance velox #26584
Conversation
amitkdutta
commented
Nov 11, 2025
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThis PR advances the Velox submodule to the latest upstream commit and updates associated build, test, and CI configurations to align with API changes. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
@amitkdutta Lets get a newer Velox version. Deepak's fix for CPR just came in and this helps Prestissimo as well. Edit: I'm suspecting the worker is crashing on handling the request. Taking a look. |
|
@amitkdutta I found the root cause. A bunch of new iceberg transform functions were added that are internal but get exposed through the API. And they don't conform to the expected function naming convention for (regular) functions. |
| name.find("$internal$") != std::string::npos || | ||
| // TODO Review. Iceberg functions, if internal should use the $internal$ | ||
| // prefix? | ||
| name.find("iceberg_") != std::string::npos || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PingLiuPing Newly added Iceberg functions don't conform to the expected name layout. I suspect they are internal for the transformations and are not exposed to the user?
In that case they probably should get the $internal$ prefix? We can clean up Velox later and open an issue if you agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@czentgr Thanks for looking. Yea we are experiencing same issue as well. Which PR exposed these functions? Can we revert it? Also we can add something so that the worker does not crash, just skip such functions.
I think its this one: facebookincubator/velox#15440
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@czentgr Thanks.
Those functions should be exposed to users. Currently Presto only support bucket function but Spark(Gluten) support all of them. And those functions has been added to Velox document https://facebookincubator.github.io/velox/functions/iceberg/functions.html.
I will update the code to use three part names.
catalog.schema.function_name
Sorry for the trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newly added Iceberg functions don't conform to the expected name layout
@czentgr Looks like we are lacking documentation for this requirement and PR time testing. Let's follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PingLiuPing Yes, Iceberg functions in Velox but are they PrestoSQL functions as well? They can be used through the Velox APIs (PlanBuilder) but are also expected to work in PrestoSQL?
Looks like some iceberg functions are registered using correct prefix: #26581 in PrestoC++.
I think the issue is that Velox is registering the functions itself instead of letting PrestoC++ call the registration (like it does for all the other functions).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@czentgr Suppose those functions been registered by Prestissimo, do we have any mechanisms to get the function prefix inside velox?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if there has been a case where a Velox function was internal but also externalized to PrestoSQL.
We can look. But I would think we have two separate registrations then, once as internal (with the appropriate prefix which gets filtered in prestoc++) and once for PrestoSQL.
Summary: Original commit changeset: ae45744c1ae1 Original Phabricator Diff: D86686271 details: prestodb/presto#26584 (comment) Reviewed By: abhash09 Differential Revision: D86821554
…ms" (facebookincubator#15475) Summary: Original commit changeset: ae45744c1ae1 Original Phabricator Diff: D86686271 details: prestodb/presto#26584 (comment) Reviewed By: abhash09 Differential Revision: D86821554
…ms" (#15475) Summary: Pull Request resolved: #15475 Original commit changeset: ae45744c1ae1 Original Phabricator Diff: D86686271 details: prestodb/presto#26584 (comment) Reviewed By: kgpai, tanjialiang, abhash09 Differential Revision: D86821554 fbshipit-source-id: 79bf0de3deec19ba5d8cd720a3abef05dc29e94b
b9695d7 to
a34dc1b
Compare