korlov42 commented on a change in pull request #9009: URL: https://github.com/apache/ignite/pull/9009#discussion_r616154789
########## File path: modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/exec/rel/MinusNode.java ########## @@ -0,0 +1,341 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.ignite.internal.processors.query.calcite.exec.rel; + +import java.util.ArrayList; +import java.util.Collections; +import java.util.HashMap; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import org.apache.calcite.rel.type.RelDataType; +import org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext; +import org.apache.ignite.internal.processors.query.calcite.exec.RowHandler; +import org.apache.ignite.internal.processors.query.calcite.exec.RowHandler.RowFactory; +import org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AggregateType; +import org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.GroupKey; +import org.apache.ignite.internal.util.typedef.F; + +/** + * Execution node for MINUS (EXCEPT) operator. + */ +public class MinusNode<Row> extends AbstractNode<Row> { Review comment: I may not really understand how the EXCEPT is supposed to work... So let's find out it first to sure we are on the same page. My understanding is matches the [Postgres definition](https://www.postgresql.org/docs/7.4/sql-select.html) (sorry, but there is no anchor for exact place). Current implementation of the execution node says that only leftmost query defines a top bound of row count, every next stage of EXCEPT could only shorten the resultset. Hence a conclusion: we could drop following stages as soon as current stage returns empty resultset. It's true that we have to complete gathering rows for current stage, but I see no reason to proceed the work a result of which we are no more interested in. > Did you mean [all=true] (not DISTINCT)? No, I meant exactly what I said. Frankly I have no clue how a query with EXCEPT ALL could be easily rewritten with ANTI JOIN since it requires a counting rows on both sides. On the other hand a query like `SELECT f1 FROM t1 EXCEPT SELECT f1 FROM t2` could be simply rewritten to `SELECT DISTINCT f1 FROM t1 ANTI JOIN t2 USING (f1)`. > Calcite uses about the same approach For some (unclear to me) reasons Calcite doesn't like SEMI and ANTI joins. And we already faced a [problem](https://issues.apache.org/jira/browse/IGNITE-14277) because of this -- 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. For queries about this service, please contact Infrastructure at: [email protected]
