gene-bordegaray commented on code in PR #23184:
URL: https://github.com/apache/datafusion/pull/23184#discussion_r3492311409
##########
datafusion/physical-expr/src/partitioning.rs:
##########
@@ -596,17 +642,39 @@ pub enum Distribution {
/// Requires children to be distributed in such a way that the same
/// values of the keys end up in the same partition
HashPartitioned(Vec<Arc<dyn PhysicalExpr>>),
+ /// Requires rows with equal values for the given keys to be colocated in
+ /// the same partition, without requiring a specific partitioning
algorithm.
+ ///
+ /// Unlike [`Self::HashPartitioned`], this can be satisfied by non-hash
+ /// partitioning such as range partitioning. A partitioning on a subset of
+ /// these keys can also satisfy this requirement because rows equal on all
+ /// required keys are also equal on any subset.
+ ///
+ /// For multi-input operators, satisfaction alone is not enough: each input
+ /// may satisfy its own key requirement while using incompatible partition
+ /// boundaries. Use [`Partitioning::co_partitioned_with`] before pairing
+ /// partitions by index.
+ KeyPartitioned(Vec<Arc<dyn PhysicalExpr>>),
}
Review Comment:
Yes I agree that supporting both is not the right move, I also am a bit wary
to just make apublic API change to this without having some operators try to
satisfy `HashPartitioned` using `Range`.
I mentioned in some comments below but would want to have a few operators
(both unary and multi-input) privately do satisfaction checks on
`HashPartitioned` before renaming or migrating to `KeyPartitioned`. I do not
want a situation like we had with dynamic filters, where there is some edge
case we don't consider before changing the public api. Let me know if you think
thats a good path (my new PR shows how this is done for aggregates: #23239 and
then would like to do one type of join before doing the full rename)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
