Planner: rule_eliminate_projection doesn't set proper schema after elimination
- 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
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