Also regarding that Projects merging is common in Calcite optimization rules, we should always remember to avoid merging for cases like the one given by Rommel. I think that would be hard.
Best, Jin XING JIN <jinxing.co...@gmail.com> 于2019年10月14日周一 上午11:51写道： > Hi, Stamatis, Danny~ > > Thanks for explain ~ > > > "The consumer in the case of P1 is the project which only needs $0, $2, > $5, > $6 so the trimmer could slim down the scan by projecting only these > fields." > > I think RelFieldTrimmer is already doing this by [1]. > But why the final BindableTableScan is not pruned ? I think the answer is > that RelFieldTrimmer merges projects when trimming fields for Project: > [2][3] > > > "RelFieldTrimmer can be used to transform the plan P1 to > plan P2 and then ProjectTableScanRule can be used to introduce the > BindableTableScan." > > If we wanna go by this approach, shall we avoid the project merging as > mentioned in RelFieldTrimmer [2][3] ? > > Well, as an independent functionality for column pruning, I still suggest > ProjectTableScanRule have the the ability to handle such complex scenarios. > > How do you think? > > Best, > Jin > > > > [1] > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L1054 > [2] > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java#L416 > > [3] > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L1327 > > Danny Chan <yuzhao....@gmail.com> 于2019年10月14日周一 上午9:42写道： > >> +1, RelFieldTrimmer is the role to trim the unused fields. >> >> Best, >> Danny Chan >> 在 2019年10月13日 +0800 AM6:25，dev@calcite.apache.org，写道： >> > >> > RelFieldTrimmer >> >
