planner: don't push down predicates over table dual

[tangenta]

What problem does this PR solve?

Issue Number: close #35527

Problem Summary:

When a table dual is used as view or subquery, the PPD(Predicate Push-Down) optimizer incorrectly pushes the predicate down to the table dual.

After rule-based optimization:

*core.LogicalProjection(*core.LogicalProjection(*core.LogicalSelection(*core.LogicalTableDual)))

After the physical optimization, the columns in condition need to be relocated using the schema of child operator(it is TableDual here). As we know, the schema of TableDual is always nil. An error is occurred.

What is changed and how it works?

This PR avoids to push the predicates to the TableDual, but keeps a Projection over it instead.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• mjonss
• xhebox

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[sre-bot]

Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/6ae53c526917b9963a50a269fd668227789d63d8

[winoros]

mysql> explain select c0 from (select null as c0) v0 where c0 is null;
+-------------------+---------+------+---------------+-----------------+
| id                | estRows | task | access object | operator info   |
+-------------------+---------+------+---------------+-----------------+
| Projection_6      | 1.00    | root |               | <nil>->Column#1 |
| └─TableDual_7     | 1.00    | root |               | rows:1          |
+-------------------+---------+------+---------------+-----------------+
2 rows in set (0.01 sec)

mysql> explain select c0 from (select null as c0) v0 where c0 is null;
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    403
Current database: test

+---------------------+---------+------+---------------+------------------+
| id                  | estRows | task | access object | operator info    |
+---------------------+---------+------+---------------+------------------+
| Selection_6         | 0.80    | root |               | isnull(Column#1) |
| └─Projection_7      | 1.00    | root |               | <nil>->Column#1  |
|   └─TableDual_8     | 1.00    | root |               | rows:1           |
+---------------------+---------+------+---------------+------------------+
3 rows in set (0.32 sec)

This change caused the above diff.
I'm also a little curious about why the normal explain select c0 from (select null as c0) v0 where c0 is null; would not trigger this bug because the view only support expanding itself now which means it should be the same with the above SQL`.

[tangenta]

I'm also a little curious about why the normal explain select c0 from (select null as c0) v0 where c0 is null; would not trigger this bug

@winoros I tried to print the logical plan in each step of logical optimization:

[optimizer.go:456] ["logicalOptimize before"] [logic=*core.LogicalProjection(*core.LogicalSelection(*core.LogicalProjection(*core.LogicalTableDual)))]
[optimizer.go:470] [logicalOptimize] [rule=column_prune] [logic=*core.LogicalProjection(*core.LogicalSelection(*core.LogicalProjection(*core.LogicalTableDual)))]
[optimizer.go:470] [logicalOptimize] [rule=projection_eliminate] [logic=*core.LogicalProjection(*core.LogicalSelection(*core.LogicalProjection(*core.LogicalTableDual)))]
[optimizer.go:470] [logicalOptimize] [rule=predicate_push_down] [logic=*core.LogicalProjection(*core.LogicalProjection(*core.LogicalTableDual))]
...
[optimizer.go:475] ["logicalOptimize after"] [logic=*core.LogicalProjection(*core.LogicalProjection(*core.LogicalTableDual))]

You can see the LogicalSelection is eliminated by "predicate_push_down" rule. This is not happened in where (c0 is null) like (null). For the operator LIKE, the first argument must be a string. Thus, a cast function is inserted automatically:

where cast((c0 is null) as string) like (null)

The "predicate_push_down" rule tries to eliminate the selection by PropagateConstant and then DeleteTrueExprs. However, because the collation of NULL("binary") is stricter than "utf8mb4_bin", which is the collation of cast((c0 is null) as string), the column substitution failed. That's why the selection is not eliminated.

Anyway, even if the selection operator is not pushed down, it shouldn't report the error "Can't find column Column#1 in schema Column: [] Unique key: []".

[mjonss]

LGTM

[xhebox]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 0325dbb

[winoros]

I used the wrong SQL for checking. Now i have no question(

[sre-bot]

TiDB MergeCI notify

🔴 Bad News! [1] CI still failing after this pr merged.
These failed integration tests don't seem to be introduced by the current PR.

CI Name	Result	Duration	Compare with Parent commit
idc-jenkins-ci-tidb/integration-common-test	🔴 failed 1, success 10, total 11	19 min	Existing failure
idc-jenkins-ci/integration-cdc-test	🟢 all 35 tests passed	26 min	Existing passed
idc-jenkins-ci-tidb/common-test	🟢 all 12 tests passed	10 min	Existing passed
idc-jenkins-ci-tidb/tics-test	🟢 all 1 tests passed	6 min 13 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2	🟢 all 28 tests passed	6 min 1 sec	Existing passed
idc-jenkins-ci-tidb/integration-ddl-test	🟢 all 6 tests passed	5 min 57 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1	🟢 all 26 tests passed	5 min 44 sec	Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test	🟢 all 1 tests passed	3 min 3 sec	Existing passed
idc-jenkins-ci-tidb/mybatis-test	🟢 all 1 tests passed	2 min 52 sec	Existing passed
idc-jenkins-ci-tidb/plugin-test	🟢 build success, plugin test success	4min	Existing passed