[ https://issues.apache.org/jira/browse/CALCITE-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17115001#comment-17115001 ]
Julian Hyde commented on CALCITE-3221: -------------------------------------- [~hyuan], I agree with [~zabetak], and I'm a bit surprised that you don't think that a new sub-class of RelNode is appropriate if we are using a new algorithm. We've never really had a discussion about when to create a new sub-class of RelNode, but I'll point out that a union based on merge will have a different cost model than a union based on concatenate-then-hash-aggregate. I think that is sufficient reason to split into different RelNode sub-classes. > Add a sort-merge union algorithm > -------------------------------- > > Key: CALCITE-3221 > URL: https://issues.apache.org/jira/browse/CALCITE-3221 > Project: Calcite > Issue Type: Improvement > Components: core > Affects Versions: 1.19.0 > Reporter: Stamatis Zampetakis > Priority: Minor > > Currently, the union operation offered by Calcite is based on a {{HashSet}} > (see > [EnumerableDefaults.union|https://github.com/apache/calcite/blob/d98856bf1a5f5c151d004b769e14bdd368a67234/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L2747]) > and necessitates reading in memory all rows before returning a single > result. > Apart from increased memory consumption the operator is blocking and also > destroys the order of its inputs. > The goal of this issue is to add a new union algorithm (EnumerableMergeUnion > ?) exploiting the fact that the inputs are sorted which consumes less memory > and retains the order of its inputs. > Most likely the implementation of the merge join can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)