Cascade's LogicalTableScan derive stats with wrong range

[lysu]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

no reproduce but see it has something wrong in code

LogicalTableScan only be used in cascade

2. What did you expect to see? (Required)

build common handle range?

3. What did you see instead (Required)

TODO

4. What is your TiDB version? (Required)

master

[jackwener]

@lysu Hi, I couldn't get your point. You think that Is it problem that BuildTableRange use LogicalTableScan?

Could you provide more details about question.

[jackwener]

If the answer is yes, there isn't problem in fact. Cascades plan use many functions in plan.core

[moonsphere]

@lysu Hi, I couldn't get your point. You think that Is it problem that BuildTableRange use LogicalTableScan?

Could you provide more details about question.

the question in here should be only building primary key range by ts.HandleCols.GetCol(0), it's assumed TableScan over PK only contains 1 column. it's ok before the clustered index feature(table scan only can use auto-generated row_id or one column int primary key), but after clustered index shipped table scan need to handle multiple columns and different type columns's PK

maybe you can test it with create table t (a int, b int, c int, primary key(a, b) clustered)..

it seems this code less adopt to clustered index feature, it should build range for multiple columns, maybe it should sth like

tidb/planner/core/logical_plans.go

Line 664 in 171d556

func (ds *DataSource) deriveCommonHandleTablePathStats(path *util.AccessPath, conds []expression.Expression, isIm bool) (bool, error) {

PS: I'm not very sure if it has the problem, but just review the code and feel it seems to have the problem, feeling free to close it if recheck it's ok :)

[jackwener]

Thanks for your reply, It was mentioned in TODO, I mistake there is other problem.