[
https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243875#comment-16243875
]
Alexey Roytman commented on CALCITE-2044:
-----------------------------------------
The cost formula shall be an implementable policy.
I.e. if I implement an "{{\XTable implements ProjectableFilterableTable\}}" and
also "{{\implements ProjectableFilterableCostEstimator\}}" then XTable has a
function to estimate this behavior.
Or, we may wish to have an {{\AbstractProjectableFilterable\}} with such cost
function (parameters like in {{\ProjectableFilterableTable.scan()\}}).
Anyway, project presence is better than project absence, and filter presence is
better than filter absence... This seems to be more universal mantra.
> Tweak cost of BindableTableScan to make sure Project is pushed through
> Aggregate
> --------------------------------------------------------------------------------
>
> Key: CALCITE-2044
> URL: https://issues.apache.org/jira/browse/CALCITE-2044
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Luis Fernando Kauer
> Assignee: Julian Hyde
> Priority: Minor
>
> Similar to [CALCITE-1876].
> Projects are not pushed to BindableTableScan when using
> ProjectableFilterableTable with aggregate functions.
> The reason is that the cost of BindableTableScan does not use projects (and
> filters), so the planner chooses a plan with Project node removed by
> ProjectRemoveRule.
> By tweaking the cost to use the number of used projects solved the problem.
> Any suggestion on the cost formula to take both projects and filters into
> account?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
