gianm commented on code in PR #15626: URL: https://github.com/apache/druid/pull/15626#discussion_r1450814491
########## sql/src/main/java/org/apache/druid/sql/calcite/rule/AggregatePullUpLookupRule.java: ########## @@ -0,0 +1,125 @@ +/* + * 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.druid.sql.calcite.rule; + +import org.apache.calcite.plan.RelOptRule; +import org.apache.calcite.plan.RelOptRuleCall; +import org.apache.calcite.plan.RelOptUtil; +import org.apache.calcite.rel.core.Aggregate; +import org.apache.calcite.rel.core.Project; +import org.apache.calcite.rel.type.RelDataType; +import org.apache.calcite.rex.RexBuilder; +import org.apache.calcite.rex.RexCall; +import org.apache.calcite.rex.RexLiteral; +import org.apache.calcite.rex.RexNode; +import org.apache.calcite.tools.RelBuilder; +import org.apache.calcite.util.ImmutableBitSet; +import org.apache.druid.query.lookup.LookupExtractor; +import org.apache.druid.sql.calcite.expression.builtin.QueryLookupOperatorConversion; +import org.apache.druid.sql.calcite.planner.PlannerContext; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Set; + +/** + * Rule that pulls {@link QueryLookupOperatorConversion#SQL_FUNCTION} up through an {@link Aggregate}. + */ +public class AggregatePullUpLookupRule extends RelOptRule +{ + private final PlannerContext plannerContext; + + public AggregatePullUpLookupRule(final PlannerContext plannerContext) + { + super(operand(Aggregate.class, operand(Project.class, any()))); + this.plannerContext = plannerContext; + } + + @Override + public void onMatch(RelOptRuleCall call) + { + final Aggregate aggregate = call.rel(0); + final Project project = call.rel(1); + final RexBuilder rexBuilder = aggregate.getCluster().getRexBuilder(); + final Set<Integer> aggCallInputs = RelOptUtil.getAllFields2(ImmutableBitSet.of(), aggregate.getAggCallList()); + + RexNode[] topProjects = null; // Projects pulled up on top of the Aggregate + RexNode[] bottomProjects = null; // Projects that stay on the bottom of the Aggregate + boolean matched = false; // Whether we found a LOOKUP call to pull up + + int dimensionIndex = 0; + for (Iterator<Integer> iterator = aggregate.getGroupSet().iterator(); iterator.hasNext(); dimensionIndex++) { + int projectIndex = iterator.next(); + final RexNode projectExpr = project.getProjects().get(projectIndex); + + if (ReverseLookupRule.isLookupCall(projectExpr) && !aggCallInputs.contains(projectIndex)) { + final RexCall lookupCall = (RexCall) projectExpr; + final String lookupName = RexLiteral.stringValue(lookupCall.getOperands().get(1)); + final LookupExtractor lookup = plannerContext.getLookup(lookupName); + + if (lookup != null && lookup.isOneToOne()) { Review Comment: Yeah, the transformation is only valid if all possible input values are in the domain of the function (i.e. they all appear as keys in the lookup). It's up to the user to ensure that's true and set the property accordingly; the system doesn't verify it. The default is `false`, so by default this rewrite won't be applied. The docs at `docs/querying/lookups.md` discuss this a bit (look at the section "Injective lookups"). Note that we use the term "injective" for the config btw rather than "bijective", but I think there isn't any difference between the concepts really in this context, because you can think of the codomain of the lookup and the value set of the lookup as being the same thing. At any rate, I don't think this is a commonly used feature, mostly because it's hard to get exactly right, and your queries can be wrong in weird ways if you get it wrong. It's meant for situations where you know you are loading your lookups and data in a way that causes the property to be true. It would be cooler, for sure, to be able to detect that these rewrites are safe to do even in cases where the user hasn't explicitly set this property. Perhaps as you suggest by looking for other filters on the query (and verifying that each lookup key maps to a distinct value). -- 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]
