Fix: Heuristic wrapper fix

[AveryQi115]

The flow of the optimization is:

OptimizeGroup(root) --> exploreGroup(children)(can only apply logical->logical) --> after exploration, there are physical exprs in the root --> optimizeInput --> optimizeGroup(children)(can apply logical to physical)

While marking the rules as deadend, we cannot mark the impl rules as fired as we might need them to start the optimizeGroup task of the children node after merging of groups even if we know the expr can never be the winner.

[AveryQi115]

After some debugging, I found merge group is ok as long as the two corresponding groups are still having optimizeGroup task after the merge. However, optimizeGroup for children nodes are called by optimizeInput, so the ancestors of the children node cannot be pruned. There might be some problems for merge group in the future if we introduce pruning. @skyzh

If the above example is too abstract, you can try Select a from (select a from (select a from t)) with MergeProjection rules registered as heuristics to see the flow of tasks.

[Sweetsuro]

LGTM - I know you're waiting for Chi though

[AveryQi115]

LGTM - I know you're waiting for Chi though

It's ok. Let's merge it first.

[skyzh]

LGTM as it only affects the heuristics-in-cascades code path. In theory, no heuristics rules in cascades should directly replace a plan node (it should only do expression optimizations), and I believe this will cause more problems for us in the future...

[skyzh]

this creates a new entry for every expr id?

[AveryQi115]

Yes, for the expr id which is used in this function.