Stamatis Zampetakis created CALCITE-4212: --------------------------------------------
Summary: Revisit cost-model to break ties between Enumerable and Bindable expressions Key: CALCITE-4212 URL: https://issues.apache.org/jira/browse/CALCITE-4212 Project: Calcite Issue Type: Improvement Reporter: Stamatis Zampetakis Most Enumerable and Bindable expressions use exactly the same cost function to compute cost. Depending on the query this may lead to different equivalent (sub) plans with exactly the same cost. This makes the plans dependent on the order that the rules are applied. Let's consider for example the following query present in {{DruidAdapterIT#testProject}} {code:sql} select "product_name", 0 as zero from "foodmart" order by "product_name"; {code} At some point during planning the optimizer needs to decide between the following plans: +Choice 1+ {noformat} EnumerableSort(sort0=[$0], dir0=[ASC]), id = 37 EnumerableInterpreter(subset=[rel#23:RelSubset#1.ENUMERABLE.[]]), id = 43 DruidQuery(subset=[rel#26:RelSubset#1.BINDABLE.[]], table=[[foodmart, foodmart]], intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]], projects=[[$3, 0]]), id = 25 {noformat} +Choice 2+ {noformat} EnumerableInterpreter, id = 61 BindableSort(subset=[rel#40:RelSubset#1.BINDABLE.[0]], sort0=[$0], dir0=[ASC]), id = 41 DruidQuery(subset=[rel#26:RelSubset#1.BINDABLE.[]], table=[[foodmart, foodmart]], intervals=[[1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z]], projects=[[$3, 0]]), id = 25 {noformat} Both choices have exactly the same cost since {{BindableSort}} and {{EnumerableSort}} use the same cost function ({{Sort#computeSelfCost}}, {{RelMdRowCount#getRowCount(Sort, RelMetadataQuery)}}). The issue can appear with various other expressions such as Project, SetOp, etc. Although the example is taken from the Druid adapter the same can happen if both Bindable and Enumerable conventions are used during planning in other use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)