[
https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245706#comment-16245706
]
Luis Fernando Kauer commented on CALCITE-2044:
----------------------------------------------
Alexey, I'd like to understand your real need.
You see, the computed cost does not have to be exact and the overall cost
depends on the costs of all other nodes in the plan.
It is used to choose between different plans, but if you don't adjust the cost
of all other nodes of the plan, like joins, filters and projects not pushed,
aggregates, then you might not get the best plan anyway.
Here we are talking about BindableTableScan cost only and how the filters and
projects change the cost.
Even though you may have expensive columns, I assume that if the query requires
expensive columns you'll have to return them anyway, so usually pushing the
used projects is desirable.
With filters is the same thing, I think.
Julian, I would like to know some counter examples to take it into account, if
you may.
> 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)
