You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Epic] Native StringView support for string functions #11790
Is your feature request related to a problem or challenge?
We are working to add complete StringView support in DataFusion, which permits potentially much faster processing of string data. See #10918 for more background.
Today, most DataFusion string functions support DataType::Utf8 and DataType::LargeUtf8 and when called with a StringView argument DataFusion will cast the argument back to DataType::Utf8 which is expensive.
To realize the full speed of StringView, we need to ensure that all string functions support the DataType::Utf8View directly.
One thing I have noticed during implementations is that some functions such as ltrim/rtrim/btrim could be more efficient if they produced Utf8View as output in addition to accepting them as input
For example, in #11920 (comment) from @Kev1n8 it is actually probably a good idea to always generate StringView as output (rather than StringArray) as it could avoid a copy.
I am thinking once we get the string functions so they can support StringView as input then we can do a second pass and optimize some functions so they produce StringView as output
Inspired by @Omega359 's great PR #11941, I have some suggestion on testing Utf8View support for functions:
Although most implementation is adapted from existing implementation, but the execution takes another path, so I think comprehensive end-to-end tests are still needed.
The good news is there already exists sqllogictests for original string functions, the only thing to do is to duplicate existing testings with Utf8View
Here are the examples on how to adapt existing test cases for Utf8View input
Activity
alamb commentedon Aug 12, 2024
One thing I have noticed during implementations is that some functions such as
ltrim/rtrim/btrimcould be more efficient if they produced Utf8View as output in addition to accepting them as inputFor example, in #11920 (comment) from @Kev1n8 it is actually probably a good idea to always generate StringView as output (rather than StringArray) as it could avoid a copy.
I am thinking once we get the string functions so they can support StringView as input then we can do a second pass and optimize some functions so they produce StringView as output
2010YOUY01 commentedon Aug 12, 2024
Inspired by @Omega359 's great PR #11941, I have some suggestion on testing
Utf8Viewsupport for functions:Although most implementation is adapted from existing implementation, but the execution takes another path, so I think comprehensive end-to-end tests are still needed.
The good news is there already exists
sqllogictests for original string functions, the only thing to do is to duplicate existing testings withUtf8ViewHere are the examples on how to adapt existing test cases for
Utf8Viewinputarrow_cast()like https://github.com/apache/datafusion/pull/11941/files#diff-51757b2b1d0a07b88551d88eabeba7f74e11b5217e44203ac7c6f613c0221196Utf8Viewcolumn likedatafusion/datafusion/sqllogictest/test_files/string_view.slt
Lines 30 to 42 in 2cf0956
alamb commentedon Aug 21, 2024
We are making pretty good progress here -- just a few more functions left 🚀
alamb commentedon Nov 21, 2024
I think we can claim this is completed. Follow on work is tracked in
alamb commentedon Nov 21, 2024
🎉