-
Notifications
You must be signed in to change notification settings - Fork 246
Chore: Use DataFusion impl of date_trunc function #2523
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
base: main
Are you sure you want to change the base?
Chore: Use DataFusion impl of date_trunc function #2523
Conversation
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.
Thanks @kazantsev-maksim
There are some compilation issues |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2523 +/- ##
=============================================
- Coverage 56.12% 41.39% -14.74%
- Complexity 976 1068 +92
=============================================
Files 119 146 +27
Lines 11743 13562 +1819
Branches 2251 2358 +107
=============================================
- Hits 6591 5614 -977
- Misses 4012 6975 +2963
+ Partials 1140 973 -167 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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 seem to recall that we implemented this because the DF version was slower.
This is a good point @parthchandra we can "steal" date_trunc bench from DF and check it out. |
Current Comet performance for
I tried running against this PR but got similar failures to the ones we are seeing in CI. |
The DataFusion implementation of date_trunc has a narrower scope than Spark's, as it only accepts TimestampType, while Spark's version additionally supports StringType and DateType. Comet does not fully support casting DateType to TimestampType yet. |
Which issue does this PR close?
Rationale for this change
What changes are included in this PR?
How are these changes tested?