[
https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245645#comment-16245645
]
Alexey Roytman commented on CALCITE-2044:
-----------------------------------------
Julian, once you talked about 80%, now they're raised to 90%. So the
{{ProjectableFilterableTable}} is improving!
...For my project I moved to {{TranslatableTable}} (implementing only
{{Filter}} and {{Project}} rules there), but it's a complicated thing, and I'm
in 3rd or 4th iteration of re-learning. Thus I compare my implementation of
{{TranslatableTable}} with the one I already have for
{{ProjectableFilterableTable}}, comparing results, performance etc. For sure,
I'd like to use {{ProjectableFilterableTable}} if it allows me the flexibility
of cost evaluation having in hand the arguments of
{{ProjectableFilterableTable.scan()}}, but alas.
> 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)
