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 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.
