-
Notifications
You must be signed in to change notification settings - Fork 159
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
What are use cases for non-nullable types? #332
Comments
I think you meant "non-nullable" in your issue title. Also, link to the thread that spawned this: substrait-io/substrait-validator#52 (comment) |
@jvanstraten You are correct. Thank you for pointing this out. Updated the title and description. |
There are a number of cases where optimizers can make smarter decisions if they can know that the data cannot have nulls. Additionally, many systems have representation and execution optimizations with non-nullable scenarios. Most databases have the ability to declare fields as non-nullable. |
Calcite allows nullable and non-nullable types. But it might have been better if it had represented nullability as a constraint, rather than part of the type. A column that goes into a filter nullable can come out not-nullable. That's more of a change of constraint rather than a change in representation. |
Can we close this? I think the answer has been given (it's not classic SQL but it can allow optimizers and engines to make more intelligent decisions and some engines support it). |
ClickHouse is an engine that makes rather heavy use of non nullable types. All naked types in clickhouse e.g., |
Folks, the type systems allows to specify nullability for each type. In SQL, all types are nullable, hence, I'm curious what's the use case for non-nullable types.
https://substrait.io/types/type_system/
Context: substrait-io/substrait-validator#52 (comment)
The text was updated successfully, but these errors were encountered: