[SPARK-40618][SQL] Fix bug in MergeScalarSubqueries rule with nested subqueries

[dtenedor]

What changes were proposed in this pull request?

There is a bug in the MergeScalarSubqueries rule for queries with subquery expressions nested inside each other, wherein the rule attempts to merge the nested subquery with its enclosing parent subquery. The result is not a valid plan and raises an exception in the optimizer. Here is a minimal reproducing case:

sql("create table test(col int) using csv")
checkAnswer(sql("select(select sum((select sum(col) from test)) from test)"), Row(null))

To fix, we disable the optimization for subqueries with nested subqueries inside them for now.

Why are the changes needed?

This fixes a bug.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Updated existing unit tests and added the reproducing case as a new test case.

[dtenedor]

Hi @peter-toth, @sigmod, @gengliangwang could you please help to review this bug fix? 🙏

[sigmod]

thanks @dtenedor!

[gengliangwang]

@dtenedor just reminder, could you check the test failure?

[dtenedor]

@dtenedor just reminder, could you check the test failure?
@gengliangwang my mistake 😦 I have updated the unit test file. That test should now show that we avoid merging nested subqueries in that case. I updated it accordingly.

[peter-toth]

Unfortunately, this is also a valid test and so it shouldn't be altered. The 2 leaf level subqueries are independent and can be merted to compute once. Similarly the 2 parents can be also merged. Admittedly, this test case is not the best, I should have used a different table than testData in the parent queries to make the test more simple.

But I don't want to block this fix so if we need it urgently I'm ok with mergint this PR but probably we can come up with a better alternative.

[peter-toth]

I think the issue is that currently we allow merging a subquery to another one that is needed to compute the subquery itself. So we should collect the (transitive) subquery references in the new plan and don't try merging the new plan to those.
@dtenedor, let me know if you want to update this PR or I can open one with the fix tomorrow.

[dtenedor]

@peter-toth Yeah, the bug is in tryMergePlans where it tries to merge a subquery plan with another plan that contains the original subquery plan inside, e.g. the regression test select(select sum((select sum(col) from t)) from t. I tried doing that by keeping sets of visited plans and checking them before merging, but it got complex since some ScalarSubqueryReferences were already converted.

We should probably merge this PR to fix planning errors while keeping most of the optimizations from this rule in the short term. Then we can follow-up to restore the remaining optimization. I put a TODO for that; with the regression test present, it should be safe to proceed from there.

[AmplabJenkins]

Can one of the admins verify this patch?

[gengliangwang]

Thanks, merging to master