Zoltán Borók-Nagy created IMPALA-15671:
------------------------------------------
Summary: Calcite: a constant equality such as 2002 = 2002 is kept
as a hash join key and partitioning expression
Key: IMPALA-15671
URL: https://issues.apache.org/jira/browse/IMPALA-15671
Project: IMPALA
Issue Type: Improvement
Components: Frontend
Reporter: Zoltán Borók-Nagy
A variant of TPC-DS q78 whose outer joins become inner joins (because of ws_qty
> 0 AND cs_qty > 0) and whose year column is fixed by ss_sold_year = 2002 gets
this plan with PLANNER=CALCITE:
{noformat}
25:HASH JOIN [INNER JOIN, PARTITIONED]
| hash predicates: 2002 = 2002, catalog_sales.cs_bill_customer_sk =
store_sales.ss_customer_sk
| fk/pk conjuncts: none
|--F19:PLAN FRAGMENT [HASH(2002,catalog_sales.cs_bill_customer_sk)]
| JOIN BUILD
| | build expressions: 2002, store_sales.ss_customer_sk
{noformat}
The year was propagated into both sides, which leaves 2002 = 2002 in the join
condition. It is kept as an equi-join key, so it is evaluated and hashed for
every build and probe row, and it appears in the exchange's partitioning
expressions. The plan's other fact join (store_sales x web_sales) has the same
2002 = 2002 key.
*Proposal:* drop always-true constant equalities from join conditions (or
simplify them to TRUE) before the hash keys and partitioning are chosen.
The same happens on master: the expected plan of the Calcite TPC-DS CTE planner
test
(testdata/workloads/functional-planner/queries/PlannerTest/tpcds_cte/tpcds-q78.test)
has "hash predicates: 2000 = 2000, ..." on the store_sales x catalog_sales
join. Not measured on its own.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
