pingcap / pingcap/tidb

Planner: rule_eliminate_projection doesn't set proper schema after elimination

Open
#50,462 0 comments 0 reactions 0 assignees View on GitHub
affects-8.5 may-affects-5.4 may-affects-6.1 may-affects-6.5 may-affects-7.1 may-affects-7.5 may-affects-8.1 severity/major sig/planner type/bug
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

https://github.com/pingcap/tidb/blob/f4ba6d71ef32ae27fd0558dab29f9294f60ccccf/pkg/planner/core/rule_eliminate_projection.go#L140
```
if childProj, ok := child.(*PhysicalProjection); ok {
childProj.SetSchema(p.Schema())
}
```
Currently, only when PhysicalProjection's child is also Projection, child will set the same schema as the eliminated projection. It may fails in the following case:
PhysicalJoin(output col_7) => PhysicalProjection0(expr: col_7, output: col_8) => PhysicalProjection1(expr: col_8, output: col_8)
In this case, PhysicalProjection0 is first detected, and after elimination, the plan would look like:
PhysicalJoin(output col_7) => PhysicalProjection1(expr: col_8, output: col_8)

It has two problems here:
1. This physical plan will fail to resolve index, since PhysicalProjection1 can't find col_8 in its child's output schema
2. In fact, PhysicalProjection1 can be eliminated, but now the rule can't eliminate it.

Note: for logical plan's eliminate_projection rule, the issue doesn't exist. However, new logical projection may be added after logical eliminate_projection rule, and be eliminated in physical optimization phase.

Contributor guide

Open the contributing guide

Research direction

Start at pkg/planner/core/rule_eliminate_projection.go around line 140 and trace how PhysicalProjection schemas change during elimination. Verify the PhysicalJoin → PhysicalProjection0 → PhysicalProjection1 case described in the issue; done means the resulting plan resolves column indexes and redundant projections can still be eliminated.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.