gianm commented on a change in pull request #9648: SQL: More straightforward
handling of join planning.
URL: https://github.com/apache/druid/pull/9648#discussion_r406463863
##########
File path:
sql/src/main/java/org/apache/druid/sql/calcite/rel/DruidJoinQueryRel.java
##########
@@ -336,10 +293,23 @@ protected RelDataType deriveRowType()
@Override
public RelOptCost computeSelfCost(final RelOptPlanner planner, final
RelMetadataQuery mq)
{
- return planner.getCostFactory()
- .makeCost(partialQuery.estimateCost(), 0, 0)
- .multiplyBy(leftRequiresSubquery ?
CostEstimates.MULTIPLIER_JOIN_SUBQUERY : 1)
- .multiplyBy(rightRequiresSubquery ?
CostEstimates.MULTIPLIER_JOIN_SUBQUERY : 1);
+ double cost;
+
+ if (computeLeftRequiresSubquery(getSomeDruidChild(left))) {
+ cost = CostEstimates.COST_JOIN_SUBQUERY;
+ } else {
+ cost = partialQuery.estimateCost();
+ }
+
+ if (computeRightRequiresSubquery(getSomeDruidChild(right))) {
+ cost += CostEstimates.COST_JOIN_SUBQUERY;
+ }
+
+ if (joinRel.getCondition().isA(SqlKind.LITERAL) &&
!joinRel.getCondition().isAlwaysFalse()) {
+ cost += CostEstimates.COST_JOIN_CROSS;
+ }
Review comment:
Currently, the native query join handling isn't smart enough to totally
eliminate a join that has a false condition. It will still evaluate the left
and right hand sides if they are subqueries. And it will still walk through
every row on the left hand side. So I think it is fair to keep considering
these costs in the cost estimator.
----------------------------------------------------------------
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]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
