I decide to create a seperate JIRA just for this work (CALCITE-3330). CALCITE-1048 has too much history and there are mulitple places in the code checking Bug.CALCITE_1048_FIXED. It would be very confusing if we resolve 1048 by adding the breath first search but not able to remove these hacks.
> On Sep 5, 2019, at 4:29 PM, Xiening Dai <xndai....@live.com> wrote: > > Hi all, > > I came across this JIRA and am not sure what its status is. The original > proposal in the bug looks reasonable to me. We currently propagate importance > improvement through a depth-first model, which could result in stack overflow > if the memo is very big and very deep. Change it into a breadth-first > algorithm seems reasonable and straightforward. > > The JIRA also mentions multiple places in the code (such as > RelMdRowCount.java) using hack to work around CALCITE 1048. But that doesn’t > seem to relate to what this JIRA intends to do. I am thinking we can scope > down this to just use breadth-first cost propagation and then we can have > separate issues logged for removing the hacks in RelMdRowCount. > > Any thoughts? Thanks.
