[
https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244275#comment-16244275
]
Julian Hyde commented on CALCITE-2044:
--------------------------------------
Agreed; it's usually better to project and to filter, but there are
counter-examples and they are crucial. [~alexeyroytman], I feel that you are
more comfortable with the "simplified" APIs such as ProjectableFilterableTable
rather than the more powerful model based on RelOptRule and cost models. No
question that the simplified APIs are good for 90% of cases; but they are very
wrong for the difficult 10%. Until you grok the volcano model I fear we are
going to find ourselves at odds over and over again.
> 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)
