planner: fix wrong row-sizes used in cost model #33845
Conversation
|
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
|
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/98d8772c6f3e4486443d8899c8732f8fd8b187bc |
|
/bench +tpch |
| └─HashJoin 91515927.49 root inner join, equal:[eq(tpch.orders.o_orderkey, tpch.lineitem.l_orderkey)] | ||
| └─IndexHashJoin 91515927.49 root inner join, inner:IndexLookUp, outer key:tpch.orders.o_orderkey, inner key:tpch.lineitem.l_orderkey, equal cond:eq(tpch.orders.o_orderkey, tpch.lineitem.l_orderkey) | ||
| ├─HashJoin(Build) 22592975.51 root inner join, equal:[eq(tpch.customer.c_custkey, tpch.orders.o_custkey)] | ||
| │ ├─TableReader(Build) 1498236.00 root data:Selection | ||
| │ │ └─Selection 1498236.00 cop[tikv] eq(tpch.customer.c_mktsegment, "AUTOMOBILE") | ||
| │ │ └─TableFullScan 7500000.00 cop[tikv] table:customer keep order:false | ||
| │ └─TableReader(Probe) 36870000.00 root data:Selection | ||
| │ └─Selection 36870000.00 cop[tikv] lt(tpch.orders.o_orderdate, 1995-03-13 00:00:00.000000) | ||
| │ └─TableFullScan 75000000.00 cop[tikv] table:orders keep order:false | ||
| └─TableReader(Probe) 163047704.27 root data:Selection | ||
| └─Selection 163047704.27 cop[tikv] gt(tpch.lineitem.l_shipdate, 1995-03-13 00:00:00.000000) | ||
| └─TableFullScan 300005811.00 cop[tikv] table:lineitem keep order:false | ||
| └─IndexLookUp(Probe) 4.05 root | ||
| ├─IndexRangeScan(Build) 7.45 cop[tikv] table:lineitem, index:PRIMARY(L_ORDERKEY, L_LINENUMBER) range: decided by [eq(tpch.lineitem.l_orderkey, tpch.orders.o_orderkey)], keep order:false | ||
| └─Selection(Probe) 4.05 cop[tikv] gt(tpch.lineitem.l_shipdate, 1995-03-13 00:00:00.000000) | ||
| └─TableRowIDScan 7.45 cop[tikv] table:lineitem keep order:false |
There was a problem hiding this comment.
I ran our TPCH bench again and this plan change won't cause regression:
| @@ -959,6 +959,8 @@ func (p *LogicalJoin) constructInnerTableScanTask( | |||
| isPartition: ds.isPartition, | |||
|
|
|||
| underInnerIndexJoin: true, | |||
| tblCols: ds.TblCols, | |||
| tblColHists: ds.TblColHists, | |||
There was a problem hiding this comment.
We use ts.StoreType but we don't explicitly set it(just implicitly set it to TiKV). Do we need to improve it in the future?
There was a problem hiding this comment.
Actually no need to set it explicitly here since IndexLookJoin is only for TiKV, but I think you are right, it's better to set it explicitly here to make it clearer, and I'll fix it in the next PR.
| is, partialCost, rowCount := ds.getOriginalPhysicalIndexScan(prop, path, false, false) | ||
| rowSize := is.indexScanRowSize(idx, ds, false) | ||
| rowSize := is.stats.HistColl.GetAvgRowSize(is.ctx, is.schema.Columns, true, false) |
There was a problem hiding this comment.
Do we change the actual logic here? In indexScanRowSize we check whether to add handleCol before calculating rowSize.
There was a problem hiding this comment.
Yes, this is a small logical change, but I think this change is acceptable since 1) it won't cause plan-regression, 2) I'll further improve it later, 3) the current implementation is too sophisticated to maintain.
|
/merge |
|
This pull request has been accepted and is ready to merge. Commit hash: 98d8772
|
What problem does this PR solve?
Issue Number: close #33844
Problem Summary: planner: fix wrong row-sizes used in cost model
What is changed and how it works?
Please see #33844 for more details.
After this PR, when using and calculating row-size, we should follow the rule below:
Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.