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
I propose to add a keyless version of CoGroup that groups both inputs in a single group, analogous to the keyless Reducer version that was added in #61
I have a use case where I need to process the output of two contracts in a single udf and I currently have to use the workaround to add a constant field and use this as grouping key.
Adding a keyless version would reduce the overhead (network traffic, serialization and code-writing) and give the compiler additional knowledge (The compiler knows that there will be only a single group and a single udf call. If setAvgRecordsEmittedPerStubCall is set, it could infer the output cardinality)
Furthermore I think this would be consequent, because CoGroup is like Reduce for multiple inputs.
The text was updated successfully, but these errors were encountered:
I am actually not too sure about that one. Keyless reducers are mostly only
valuable if they are combinable. What would be the use case for a key-less
cogroup?
Am 20.03.2014 17:25 schrieb "Robert Metzger" notifications@github.com:
We should implement this for the new Java API #463#463
.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/100#issuecomment-38188477
.
I propose to add a keyless version of CoGroup that groups both inputs in a single group, analogous to the keyless Reducer version that was added in #61
I have a use case where I need to process the output of two contracts in a single udf and I currently have to use the workaround to add a constant field and use this as grouping key.
Adding a keyless version would reduce the overhead (network traffic, serialization and code-writing) and give the compiler additional knowledge (The compiler knows that there will be only a single group and a single udf call. If setAvgRecordsEmittedPerStubCall is set, it could infer the output cardinality)
Furthermore I think this would be consequent, because CoGroup is like Reduce for multiple inputs.
The text was updated successfully, but these errors were encountered: