-
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
Move WindowNode and JoinNode variations to the SPI #23976
base: master
Are you sure you want to change the base?
Conversation
1ce43fa
to
bcaa7c9
Compare
Thanks for the release note entry! Just a nit.
|
bcaa7c9
to
ad8fd08
Compare
sorry don't review yet. I changed the protocol files directly, and I need to generate them instead. |
ecd0ab5
to
9b61627
Compare
this should be ready for review now. thanks! |
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 @rschlussel for these changes.
presto-native-execution/presto_cpp/presto_protocol/core/presto_protocol_core.yml
Show resolved
Hide resolved
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.
Overall lgtm!
Just for usage of ImmutableMap/ImmutableSet I am not sure if we are relying on the order preserving property here, if yes, it will be better if we change it to LinkedHashMap/LinkedHashSet.
this.filter = filter; | ||
this.leftHashVariable = leftHashVariable; | ||
this.rightHashVariable = rightHashVariable; | ||
this.distributionType = distributionType; | ||
this.dynamicFilters = ImmutableMap.copyOf(dynamicFilters); | ||
this.dynamicFilters = unmodifiableMap(new HashMap<>(dynamicFilters)); |
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.
Should it be using LinkedHashMap to preserve order, which was guaranteed by ImmutableMap?
.addAll(right.getOutputVariables()) | ||
.build(); | ||
|
||
Set<VariableReferenceExpression> inputSymbols = new HashSet<>(); |
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.
LinkedHashSet to keep original order?
|
||
this.source = source; | ||
this.prePartitionedInputs = ImmutableSet.copyOf(prePartitionedInputs); | ||
this.prePartitionedInputs = unmodifiableSet(new HashSet<>(prePartitionedInputs)); |
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.
LinkedHashSet?
this.specification = specification; | ||
this.windowFunctions = ImmutableMap.copyOf(windowFunctions); | ||
this.windowFunctions = unmodifiableMap(new HashMap<>(windowFunctions)); |
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.
LinkedHashMap?
} | ||
|
||
public Set<VariableReferenceExpression> getCreatedVariable() | ||
{ | ||
return windowFunctions.keySet(); | ||
return unmodifiableSet(windowFunctions.keySet()); |
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.
Why we need change here?
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.
you're right, not needed. I wasn't sure if the set view of the unmodifiable map would also be unmodifiable, but it is.
904e3c0
to
622e0aa
Compare
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 @rschlussel. LGTM for native changes. Have a minor nit in the rest of the code.
@@ -11,18 +11,30 @@ | |||
* See the License for the specific language governing permissions and | |||
* limitations under the License. | |||
*/ | |||
package com.facebook.presto.sql.planner.plan; | |||
|
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.
The license is repeated twice. Please delete it.
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! fixed
Move the above plan nodes to the SPI so that they can be used by plugin PlanCheckers.
With JoinNode moved to the SPI, ConnectorJoinNode is no longer necessary. Remove it and replace references with JoinNode.
3206477
622e0aa
to
3206477
Compare
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 @rschlussel LGTM for native changes.
Description
Move WindowNode, JoinNode, SemiJoinNode, MergeJoinNode, and SpatialJoinNode to the SPI
Motivation and Context
This change is required for using these nodes in plugin PlanCheckers and ConnectorPlanOptimizers. See e.g. discussion here #23596 (comment).
Impact
WindowNode, JoinNode, SemiJoinNode, MergeJoinNode, and SpatialJoinNode are added to the SPI. ConnectorJoinNode is removed from the SPI
Test Plan
CI
Contributor checklist
Release Notes
Please follow release notes guidelines and fill in the release notes below.