CALCITE-1048 Make metadata more robust

[Xiening Dai <xn...@live.com>]

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.

Re: CALCITE-1048 Make metadata more robust

[Xiening Dai <xn...@live.com>]

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