Avoid adding redundant SubqueryAlias.

[jackwener]

Which issue does this PR close?

Closes #4383.

Rationale for this change

What changes are included in this PR?

Merge SubqueryAlias.

Are these changes tested?

test

• merge two alias.
• merge three alias (optimize again after optimize self)

Are there any user-facing changes?

[mingmwang]

I think SubqueryAlias is just temp struct in the plan tree for scoping names. The SubqueryAlias should be removed totally from the plan tree at an early phase of the logical planing by modifying the inner plan's qualify names.
Then the rest of the other logical rules do not need to deal with SubqueryAlias anymore.

[mingmwang]

In physical plan, there is no SubqueryAlias either. I think SubqueryAlias can be remove earlier to simply other logical rules.

[jackwener]

I think SubqueryAlias is just temp struct in the plan tree for scoping names. The SubqueryAlias should be removed totally from the plan tree at an early phase of the logical planing by modifying the inner plan's qualify names.
Then the rest of the other logical rules do not need to deal with SubqueryAlias anymore.

Look like we can add it in planner.

When we add subquery alias, if child is subquery alias, we just need to change the name.

I don't have much preference for these two options.

[alamb]

This PR seems like an improvement to me -- we can further improve things in follow on PRs -- thanks @jackwener

[jackwener]

wait for merge it.

I am curious about why we product the redundant Alias. If we do this optimization, it will make hard to find the reason.

[alamb]

Converting to a draft so we don't accidentally merge it

[jackwener]

More optimization #4484 (comment)

I will try to do include #4484 (comment)

It's from comment @mingmwang in #4484

[alamb]

I wonder if this PR is still relevant

[jackwener]

I wonder if this PR is still relevant

I should close it😂.
This optimization is more complicated than I thought at the beginning, I am ready to do more complete optimization.