-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
[Draft] Add support to filter out plans that use Timestamp with Timezone #23179
base: master
Are you sure you want to change the base?
Conversation
if (auto joinNode = | ||
std::dynamic_pointer_cast<const core::AbstractJoinNode>(planNode)) { |
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.
Can AbstractJoinNode be used standalone?
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.
Yes, it would cover both HashJoin and MergeJoin.
return true; | ||
} | ||
} | ||
} |
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.
AggregationNode::aggregates_::call is a CallTypedExprPtr that can contain a LambdaTypedExprPtr as input. Should we check it too?
@gggrace14 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
8ef9d99
to
1ec636e
Compare
@kgpai has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
1ec636e
to
5c38d5a
Compare
@kgpai has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
5c38d5a
to
064a415
Compare
@kgpai has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@kgpai @gggrace14 @kagamiori : Am curious why the invalidation happens during Prestissimo plan conversion instead of the Presto sql parser/semantic validation of the plan ? This code is brittle and could need a lot of tweaking. Its better to reject such a query at the co-ordinator itself if we are using native engine. It would be cleaner to drop the Timestamp with Timezone type and functions from the list here for native engine There could be other approaches as well. @tdcmeehan : Would be great to hear your thoughts. |
064a415
to
1a34455
Compare
@kgpai has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@aditi-pandit We plan to fix this in velox as quickly as possible. We are putting this interim solution guarded by a query config and intend to remove it as soon as velox support is landed (which we expected to be done in a few weeks). Don't want to add any change in co-ordinator at this moment since its temporary. Ideally we want to make the velox change, but it will require a few weeks. |
1a34455
to
9200982
Compare
@kgpai has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Understood that this is a temporary measure. But I don't understand the hesitation around adding this into the coordinator? It would just be a better check--it would occur during analysis, rather than during execution (which is after resources have been allocated, after queueing, tasks have been spun up and splits have begun to be enumerated). I also think it would just be simpler to put it there. |
@tdcmeehan @aditi-pandit Yea coordinator is definitely a better place, I am trying here |
Description
This change causes the native worker to throw if Timestamp with Timezone is encountered in the plan. This is gated on the configuration property 'fail_on_timestamp_with_timezone'.
Motivation and Context
Due to issue facebookincubator/velox#10338, there can be cases where comparisons with Timestamp with Timezone can be wrong.
Impact
Will add further details soon.
Test Plan
Working on adding tests.