You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Alexey Roytman (JIRA)" <ji...@apache.org> on 2017/11/08 13:12:00 UTC
[jira] [Commented] (CALCITE-2044) Tweak cost of BindableTableScan
to make sure Project is pushed through Aggregate
[ 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)